보안 및 컴플라이언스

컨테이너에서는 애플리케이션과 모든 종속 항목을 변경하지 않고 개발에서 테스트 및 프로덕션으로 승격할 수 있는 단일 이미지로 패키징합니다. 컨테이너는 다른 컨테이너와 밀접하게 작동하는 더 큰 애플리케이션의 일부일 수 있습니다.

컨테이너에서는 물리 서버, 가상 머신(VM) 및 프라이빗 또는 퍼블릭 클라우드와 같은 환경 및 여러 배치 대상 사이에 일관성을 제공합니다.

컨테이너를 사용하면 다음과 같은 이점이 있습니다.

Linux 컨테이너에 관한 자세한 내용은 Red Hat Customer Portal의 Linux 컨테이너 이해를 참조하십시오. RHEL 컨테이너 툴에 관해 알아보려면 RHEL 제품 설명서의 컨테이너 빌드, 실행 및 관리를 참조하십시오.

컨테이너화된 애플리케이션이 배포, 실행 및 관리되는 방식을 자동화하는 것이 OpenShift Container Platform과 같은 플랫폼의 역할입니다. OpenShift Container Platform의 핵심은 쿠버네티스 프로젝트를 사용하여 확장 가능한 데이터 센터의 여러 노드에서 컨테이너를 조정하는 엔진을 제공하는 것입니다.

쿠버네티스는 프로젝트에서 지원 가능성을 보장하지 않는 여러 다른 운영 체제 및 애드온 구성요소를 사용하여 실행할 수 있는 프로젝트입니다. 결과적으로 쿠버네티스 플랫폼마다 보안이 다를 수 있습니다.

OpenShift Container Platform은 쿠버네티스 보안을 잠그고 다양한 확장 구성요소와 플랫폼을 통합하도록 설계되었습니다. 이를 위해 OpenShift Container Platform에서는 운영 체제, 인증, 스토리지, 네트워킹, 개발 툴, 기본 컨테이너 이미지 및 기타 여러 구성요소를 포함하는 광범위한 오픈소스 기술의 Red Hat 에코 시스템을 활용합니다.

OpenShift Container Platform은 플랫폼에서 실행 중인 컨테이너화된 애플리케이션 외에도 플랫폼 자체의 취약점을 발견하고 신속하게 수정 사항을 배포하는 Red Hat의 환경을 활용할 수 있습니다. Red Hat 환경에서는 새로운 구성요소가 사용 가능하게 되면 OpenShift Container Platform과 효율적으로 통합하고 개별 고객 요구 사항에 맞게 기술을 조정하는 범위까지 기능이 확장됩니다.

컨테이너를 사용하면 동일한 커널 및 컨테이너 런타임을 통해 각 컨테이너를 가동하여 동일한 호스트에서 실행되도록 많은 애플리케이션을 배포하는 작업이 단순화됩니다. 애플리케이션은 많은 사용자가 소유할 수 있으며, 개별적으로 유지되기 때문에 서로 다르거나 호환되지 않는 버전의 애플리케이션도 문제없이 동시에 실행될 수 있습니다.

Linux에서 컨테이너는 특별한 유형의 프로세스이므로 컨테이너 보안은 여러 가지 면에서 기타 실행 중인 프로세스를 보호하는 것과 비슷합니다. 컨테이너를 실행하는 환경은 컨테이너를 서로 보호할 뿐만 아니라 호스트에서 실행 중인 다른 프로세스 및 컨테이너로부터 호스트 커널을 보호할 수 있는 운영 체제로 시작합니다.

OpenShift Container Platform 4.16은 RHEL(Red Hat Enterprise Linux)을 작업자 노드로 사용하는 옵션과 함께 RHCOS 호스트에서 실행되므로 다음 개념이 배포된 모든 OpenShift Container Platform 클러스터에 기본적으로 적용됩니다. 이러한 RHEL 보안 기능은 OpenShift Container Platform에서 컨테이너를 더 안전하게 실행할 수 있게 하는 핵심 요소입니다.

RHCOS는 OpenShift Container Platform 클러스터에서 컨트롤 플레인(마스터) 및 작업자 노드로 작동하도록 특별히 구성된 RHEL(Red Hat Enterprise Linux) 버전입니다. 따라서 RHCOS는 쿠버네티스 및 OpenShift Container Platform 서비스와 함께 컨테이너 워크로드를 효율적으로 실행하도록 조정됩니다.

OpenShift Container Platform 클러스터에서 RHCOS 시스템을 추가로 보호하려면 호스트 시스템 자체를 관리하거나 모니터링하는 컨테이너를 제외한 대부분의 컨테이너는 루트가 아닌 사용자로 실행해야 합니다. 고유한 OpenShift Container Platform 클러스터를 보호하는 데 권장되는 모범 사례는 권한 수준을 낮추거나 가능한 최소 권한으로 컨테이너를 생성하는 것입니다.

기존 가상화에서는 동일한 물리적 호스트에서 애플리케이션 환경을 분리한 상태로 유지할 수 있는 또 다른 방법을 제공합니다. 그러나 가상 머신은 컨테이너와 다른 방식으로 작동합니다. 가상화는 게스트 가상 머신(VM)을 가동시키는 하이퍼바이저를 사용하며, 각 가상 머신에는 실행 중인 커널로 표시되는 자체 운영 체제(OS)와 실행 중인 애플리케이션 및 해당 종속 항목이 있습니다.

VM을 사용하면 하이퍼바이저에서 게스트 간에 서로 분리하고 호스트 커널에서 게스트를 분리합니다. 하이퍼바이저에 액세스하는 개인과 프로세스 수가 적어지므로 물리 서버의 공격 면적을 줄입니다. 보안은 여전히 모니터링해야 하지만, 하나의 게스트 VM은 하이퍼바이저 버그를 사용하여 다른 VM 또는 호스트 커널에 액세스할 수 있습니다. 또한 OS에 패치가 필요한 경우 해당 OS를 사용하는 모든 게스트 VM에서 패치를 적용해야 합니다.

컨테이너는 게스트 VM 내부에서 실행될 수 있으며 이와 같은 조치 바람직한 경우가 있을 수 있습니다. 예를 들어, 애플리케이션을 클라우드로 수정 없이 그대로 리프트 앤 시프트(lift-and-shift) 방식으로 배포하고 이동하기 위해 컨테이너에 기존 애플리케이션을 배포할 수 있습니다.

그러나 단일 호스트에서 컨테이너를 분리하면 더 가볍고 유연하며 쉽게 확장되는 배포 솔루션이 제공됩니다. 이 배포 모델은 특히 클라우드 네이티브 애플리케이션에 적합합니다. 컨테이너는 일반적으로 VM보다 훨씬 작으며 메모리와 CPU 사용량이 적습니다.

컨테이너와 VM의 차이점에 관해 알아보려면 RHEL 7 컨테이너 설명서의 Linux 컨테이너와 KVM 가상화 비교를 참조하십시오.

OpenShift Container Platform을 배포할 때 설치 프로그램 프로비저닝 인프라(사용 가능한 플랫폼이 여러 개) 또는 사용자가 프로비저닝한 자체 인프라 중에서 선택할 수 있습니다. FIPS 모드 활성화 또는 처음 부팅 시 필요한 커널 모듈 추가와 같은 일부 낮은 수준의 보안 관련 구성은 사용자 프로비저닝 인프라를 활용할 수 있습니다. 마찬가지로 사용자 프로비저닝 인프라는 연결 해제된 OpenShift Container Platform 배포에 적합합니다.

OpenShift Container Platform의 보안 향상 및 기타 구성 변경과 관련된 목표는 다음과 같습니다.

이러한 목표를 달성하기 위해 대부분의 노드 변경은 설치 중 Ignition을 사용하거나 나중에 Machine Config Operator가 노드 세트에 적용하는 MachineConfig를 사용하여 수행해야 합니다. 이러한 방식으로 수행할 수 있는 보안 관련 구성 변경의 예는 다음과 같습니다.

Machine Config Operator 외에도 CVO(Cluster Version Operator)에서 관리하며 OpenShift Container Platform 인프라를 구성하는 데 사용할 수 있는 Operator는 여러 가지가 있습니다. CVO를 사용하면 OpenShift Container Platform 클러스터 업데이트의 여러 요소를 자동화할 수 있습니다.

RHEL 8 보안 강화 가이드에서는 RHEL 시스템의 보안 접근 방법을 설명합니다.

이 가이드를 사용하여 암호화에 접근하고 취약점을 평가하며 다양한 서비스에 대한 위협을 평가하는 방법을 알아봅니다. 마찬가지로 컴플라이언스 표준을 스캔하고, 파일 무결성을 확인하며, 감사를 수행하고, 스토리지 장치를 암호화하는 방법을 배울 수 있습니다.

강화하려는 기능에 관한 지식을 통해 RHCOS에서 강화할 방법을 결정할 수 있습니다.

OpenShift Container Platform에서 RHCOS 시스템을 직접 수정하지 않는 것이 좋습니다. 대신 작업자 노드 및 컨트롤 플레인 노드와 같은 노드 풀의 시스템 수정을 고려해야 합니다. 베어 메탈이 아닌 설치에서 새 노드가 필요한 경우 원하는 유형의 새 노드를 요청할 수 있으며 RHCOS 이미지와 이전에 수정한 사항으로 노드를 생성합니다.

설치 전, 설치 중 및 클러스터가 가동되어 실행된 후에 RHCOS를 수정할 기회가 있습니다.

Red Hat Container Registries에 대한 컨테이너 서명 검증을 활성화하려면 이러한 레지스트리의 이미지를 확인하는 키를 지정하는 서명 확인 정책 파일을 작성해야 합니다. RHEL8 노드의 경우 레지스트리는 기본적으로 /etc/containers/registries.d 에 이미 정의되어 있습니다.

머신 구성을 클러스터에 적용한 후 머신 구성 컨트롤러에서 새 MachineConfig 오브젝트를 감지하고 새로운 rendered-worker-<hash> 버전을 생성합니다.

각 OpenShift Container Platform 릴리스 이미지는 변경할 수 없으며 Red Hat 프로덕션 키를 사용하여 서명됩니다. OpenShift Container Platform 업데이트 또는 설치 중에 릴리스 이미지에서 확인 가능한 서명이 없는 컨테이너 이미지를 배포할 수 있습니다. 서명된 각 릴리스 이미지 다이제스트는 변경할 수 없습니다. 릴리스 이미지의 각 참조는 다른 이미지의 변경 불가능한 다이제스트이므로 콘텐츠를 전송하여 신뢰할 수 있습니다. 즉, 릴리스 이미지의 서명은 모든 릴리스 콘텐츠의 유효성을 검사합니다.

예를 들어 검증 가능한 서명이 없는 이미지 참조는 서명된 OpenShift Container Platform 릴리스 이미지에 포함되어 있습니다.

$ oc adm release info  quay.io/openshift-release-dev/ ocp-release@sha256:2309578b68c5666dad62aed696f1f9d778ae1a089ee461060ba7b9514b7ca417 -o pullspec 1
quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9aafb914d5d7d0dec4edd800d02f811d7383a7d49e500af548eab5d00c1bffdb 2

FIPS 컴플라이언스는 보안 수준이 높은 환경에서 요구되는 가장 중요한 구성요소 중 하나로, 지원되는 암호화 기술만 노드에서 허용합니다.

OpenShift Container Platform 컴플라이언스 프레임워크에 대한 Red Hat의 관점을 이해하려면 OpenShift 보안 가이드의 위험 관리 및 규제 준비 장을 참조하십시오.

애플리케이션 및 인프라는 쉽게 사용할 수 있는 구성요소로 구성되며, 대부분은 Linux 운영 체제, JBoss Web Server, PostgreSQL 및 Node.js와 같은 오픈소스 패키지입니다.

이러한 패키지의 컨테이너화된 버전도 제공됩니다. 그러나 패키지의 원래 위치, 사용된 버전, 빌드한 사람 및 악성 코드가 있는지 여부를 알아야 합니다.

답변해야 할 몇 가지 질문은 다음과 같습니다.

Red Hat UBI(Universal Base Images)의 컨테이너를 빌드하여 컨테이너 이미지의 기초가 Red Hat Enterprise Linux에 포함된 동일한 RPM 패키지 소프트웨어로 구성되게 합니다. UBI 이미지를 사용하거나 재배포하는 데 서브스크립션이 필요하지 않습니다.

컨테이너 자체의 지속적인 보안을 보장하기 위해 RHEL에서 직접 사용되거나 OpenShift Container Platform에 추가된 보안 스캔 기능을 통해 사용 중인 이미지에 취약점이 있을 때 경고할 수 있습니다. OpenSCAP 이미지 스캔은 RHEL에서 사용할 수 있으며 Red Hat Quay Container Security Operator 를 추가하여 OpenShift Container Platform에서 사용하는 컨테이너 이미지를 확인할 수 있습니다.

컨테이너화된 애플리케이션을 생성하려면 일반적으로 운영 체제에서 제공하는 구성요소를 제공하는 신뢰할 수 있는 기본 이미지로 시작합니다. 여기에는 라이브러리, 유틸리티 및 운영 체제의 파일 시스템에서 애플리케이션에 표시될 것으로 예상되는 기타 기능이 포함됩니다.

Red Hat UBI(Universal Base Image)는 자체 컨테이너를 구축하는 모든 사용자가 Red Hat Enterprise Linux rpm 패키지 및 기타 콘텐츠를 사용하여 전적으로 구성된 컨테이너로 시작하도록 생성되었습니다. 이 UBI 이미지는 보안 패치로 최신 상태를 유지하고 고유 소프트웨어를 포함하도록 빌드된 컨테이너 이미지를 자유롭게 사용하고 재배포하도록 정기적으로 업데이트됩니다.

다른 UBI 이미지의 상태를 찾고 확인하려면 Red Hat Ecosystem Catalog를 검색하십시오. 보안 컨테이너 이미지의 생성자는 다음과 같은 일반적인 두 가지 유형의 UBI 이미지에 관심이 있을 수 있습니다.

UBI 이미지는 자유롭게 재배포할 수 있지만, 이러한 이미지에 관한 Red Hat 지원은 Red Hat 제품 서브스크립션을 통해서만 제공됩니다.

표준, 최소 및 초기화 UBI 이미지에서 사용하고 빌드하는 방법에 관한 정보는 Red Hat Enterprise Linux 설명서에서 Red Hat Universal Base 이미지 사용을 참조하십시오.

RHEL(Red Hat Enterprise Linux) 시스템의 경우 OpenSCAP 스캔은 openscap-utils 패키지에서 사용할 수 있습니다. RHEL에서 openscap-podman 명령을 사용하여 이미지의 취약점을 스캔할 수 있습니다. Red Hat Enterprise Linux 설명서에서 컨테이너 및 컨테이너 이미지에서 취약점 스캔을 참조하십시오.

OpenShift Container Platform을 사용하면 CI/CD 프로세스에서 RHEL 스캐너를 활용할 수 있습니다. 예를 들어 소스 코드의 보안 결함을 테스트하는 정적 코드 분석 툴과 오픈소스 라이브러리에서 알려진 취약점과 같은 메타데이터를 제공하기 위해 해당 라이브러리르 식별하는 소프트웨어 구성 분석 툴을 통합할 수 있습니다.

OpenShift Container Platform은 오브젝트 주석을 사용하여 기능을 확장합니다. 취약점 스캐너와 같은 외부 툴에서는 메타데이터로 이미지 오브젝트에 주석을 달아 결과를 요약하고 Pod 실행을 제어할 수 있습니다. 이 섹션에서는 이 주석의 인식된 형식을 설명하므로 유용한 데이터를 사용자에게 표시하기 위해 콘솔에서 안정적으로 사용할 수 있습니다.

quality.images.openshift.io/<qualityType>.<providerId>: {}

quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}

{
  "name": "OpenSCAP",
  "description": "OpenSCAP vulnerability score",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://www.open-scap.org/930492",
  "compliant": true,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
    { "label": "important", "data": "12", "severityIndex": 2, "reference": null },
    { "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
    { "label": "low", "data": "26", "severityIndex": 0, "reference": null }
  ]
}

{
  "name": "Red Hat Ecosystem Catalog",
  "description": "Container health index",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://access.redhat.com/errata/RHBA-2016:1566",
  "compliant": null,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
  ]
}

$ oc annotate image <image> \
    quality.images.openshift.io/vulnerability.redhatcatalog='{ \
    "name": "Red Hat Ecosystem Catalog", \
    "description": "Container health index", \
    "timestamp": "2020-06-01T05:04:46Z", \
    "compliant": null, \
    "scannerVersion": "1.2", \
    "reference": "https://access.redhat.com/errata/RHBA-2020:2347", \
    "summary": "[ \
      { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'

annotations:
  images.openshift.io/deny-execution: true

$ curl -X PATCH \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/merge-patch+json" \
  https://<openshift_server>:6443/apis/image.openshift.io/v1/images/<image_id> \
  --data '{ <image_annotation> }'

{
"metadata": {
  "annotations": {
    "quality.images.openshift.io/vulnerability.redhatcatalog":
       "{ 'name': 'Red Hat Ecosystem Catalog', 'description': 'Container health index', 'timestamp': '2020-06-01T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2020:2347', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
    }
  }
}

다운로드 및 배포된 컨테이너 이미지의 콘텐츠를 스캔하고 추적하는 데 사용할 수 있는 툴이 있습니다. 그러나 컨테이너 이미지의 공용 소스가 많이 있습니다. 공용 컨테이너 레지스트리를 사용하는 경우 신뢰할 수 있는 소스를 사용하여 보호 계층을 추가할 수 있습니다.

불변 컨테이너를 관리할 때는 보안 업데이트를 사용하는 것이 특히 중요합니다. 불변 컨테이너는 실행 중에 변경되지 않는 컨테이너입니다. 불변 컨테이너를 배포할 때 하나 이상의 바이너리를 대체하기 위해 실행 중인 컨테이너로 들어가지 않습니다. 운영 관점에서 컨테이너를 변경하는 대신 업데이트된 컨테이너 이미지를 재빌드하고 재배포하여 컨테이너를 교체합니다.

Red Hat 인증 이미지는 다음과 같습니다.

알려진 취약점 목록은 지속적으로 늘어나므로 시간 경과에 따라 배포된 컨테이너 이미지의 콘텐츠와 새로 다운로드한 이미지의 콘텐츠를 추적해야 합니다. RHSA(Red Hat Security Advisories)를 사용하여 Red Hat 인증 컨테이너 이미지에서 새로 발견된 문제를 경고하고 업데이트된 이미지로 안내할 수 있습니다. 또는 Red Hat Ecosystem Catalog로 이동하여 각 Red Hat 이미지에 관한 기타 보안 관련 문제를 조회할 수 있습니다.

Red Hat에서는 Red Hat Ecosystem Catalog의 컨테이너 이미지 섹션에서 Red Hat 제품 및 파트너 제품의 인증된 컨테이너 이미지를 나열합니다. 해당 카탈로그에서 CVE, 소프트웨어 패키지 목록 및 상태 점수를 포함하여 각 이미지의 세부 정보를 볼 수 있습니다.

Red Hat 이미지는 실제로 공개 컨테이너 레지스트리(registry.access.redhat.com) 및 인증된 레지스트리(registry.redhat.io)로 표시되는 Red Hat Registry에 저장됩니다. 둘 다 기본적으로 동일한 컨테이너 이미지 세트를 포함하며 registry.redhat.io에는 Red Hat 서브스크립션 인증서로 인증해야 하는 추가 이미지가 포함됩니다.

Red Hat에서 컨테이너 콘텐츠에 취약점이 있는지 모니터링하고 정기적으로 업데이트합니다. Red Hat에서 glibc, DROWN 또는 Dirty Cow에 대한 수정 사항과 같은 보안 업데이트를 릴리스하면 영향을 받는 컨테이너 이미지도 다시 빌드되어 Red Hat Registry에 푸시됩니다.

Red Hat에서는 상태 색인을 사용하여 Red Hat Ecosystem Catalog를 통해 제공되는 각 컨테이너의 보안 위험을 반영합니다. 컨테이너에서는 Red Hat과 에라타 프로세스에서 제공하는 소프트웨어를 사용하므로 오래되어 해지된 컨테이너는 안전하지 않은 반면 새로운 컨테이너는 더 안전합니다.

컨테이너의 수명을 설명하기 위해 Red Hat Ecosystem Catalog에서는 평가 시스템을 사용합니다. 최신 등급은 이미지에 사용 가능한 가장 오래되고 가장 심각한 보안 정오표 수치입니다. "A"는 "F"보다 최신입니다. 이 평가 시스템에 관한 자세한 내용은 Red Hat Ecosystem Catalog 내부에서 사용되는 컨테이너 상태 색인 등급을 참조하십시오.

Red Hat 소프트웨어와 관련된 보안 업데이트 및 취약점에 관한 자세한 내용은 Red Hat 제품 보안 센터를 확인하십시오. Red Hat Security Advisories를 확인하여 특정 권고와 CVE를 검색하십시오.

OpenShift Container Platform에는 컨테이너 이미지를 관리하는 데 사용할 수 있는 플랫폼의 통합 구성요소로 실행되는 프라이빗 레지스트리인 OpenShift Container Registry가 포함되어 있습니다. OpenShift Container Registry에서는 누가 어떤 컨테이너 이미지를 가져오고 푸시하는지 관리할 수 있는 역할 기반 액세스 제어를 제공합니다.

OpenShift Container Platform에서는 Red Hat Quay와 같이 이미 사용 중인 다른 프라이빗 레지스트리와의 통합도 지원합니다.

Red Hat Quay는 Red Hat에서 제공하는 엔터프라이즈급 컨테이너 레지스트리 제품입니다. Red Hat Quay의 개발은 업스트림 프로젝트 Quay를 통해 수행됩니다. Red Hat Quay는 온프레미스 또는 Quay.io에서 호스팅된 Red Hat Quay 버전을 통해 배포할 수 있습니다.

Red Hat Quay의 보안 관련 기능은 다음과 같습니다.

OpenShift Container Platform과 Red Hat Quay는 지속적으로 통합되며, 특히 흥미로운 OpenShift Container Platform Operators가 여러 개 있습니다. Quay Bridge Operator 를 사용하면 내부 OpenShift 이미지 레지스트리를 Red Hat Quay로 교체할 수 있습니다. Red Hat Quay Container Security Operator 를 사용하면 Red Hat Quay 레지스트리에서 가져온 OpenShift Container Platform에서 실행되는 이미지의 취약점을 확인할 수 있습니다.

컨테이너 빌드를 위한 표준 플랫폼으로 OpenShift Container Platform을 사용하면 빌드 환경의 보안을 보장할 수 있습니다. "한 번만 빌드하여 어디에나 배포" 철학을 준수하면 빌드 프로세스의 제품을 프로덕션에 정확히 배포할 수 있습니다.

컨테이너의 불변성을 유지 관리하는 것도 중요합니다. 실행 중인 컨테이너에 패치를 적용하지 말고 다시 빌드하여 재배치해야 합니다.

소프트웨어가 빌드, 테스트 및 프로덕션 단계를 진행해 갈 때 소프트웨어 공급망을 구성하는 툴을 신뢰하는 것이 중요합니다. 다음 그림에서는 컨테이너화된 소프트웨어를 위한 신뢰할 수 있는 소프트웨어 공급망에 통합될 수 있는 프로세스와 툴을 보여줍니다.

OpenShift Container Platform은 신뢰할 수 있는 코드 리포지토리(예: GitHub) 및 개발 플랫폼(예: Che)과 통합되어 보안 코드를 생성하고 관리할 수 있습니다. 단위 테스트에서는 Cucumber 및 JUnit을 사용합니다. 컨테이너에서 Anchore 또는 Twistlock의 취약점 및 컴플라이언스 문제가 있는지 검사하고 AtomicScan 또는 Clair와 같은 이미지 검색 툴을 사용할 수 있습니다. Sysdig와 같은 툴을 사용하면 컨테이너화된 애플리케이션을 지속적으로 모니터링할 수 있습니다.

S2I(Source-to-Image)를 사용하여 소스 코드와 기본 이미지를 결합할 수 있습니다. 빌더 이미지는 S2I를 사용하므로 개발 및 운영 팀이 재현 가능한 빌드 환경에서 협업할 수 있습니다. UBI(Universal Base Image) 이미지로 사용 가능한 Red Hat S2I 이미지를 사용하면 실제 RHEL RPM 패키지에서 빌드된 기본 이미지로 소프트웨어를 자유롭게 재배포할 수 있습니다. Red Hat에서는 이를 허용하기 위해 서브스크립션 제한 사항을 제거했습니다.

개발자가 빌드 이미지를 사용하여 애플리케이션용 Git로 코드를 커밋하면 OpenShift Container Platform에서는 다음 기능을 수행할 수 있습니다.

통합 OpenShift Container Registry를 사용하여 최종 이미지에 대한 액세스를 관리할 수 있습니다. S2I 및 기본 빌드 이미지가 자동으로 OpenShift Container Registry로 푸시됩니다.

포함된 Jenkins for CI 외에도 RESTful API를 사용하여 자체 빌드 및 CI 환경을 OpenShift Container Platform과 통합하고 API 호환 이미지 레지스트리를 사용할 수 있습니다.

일부 시나리오에서는 빌드 작업을 할 때 종속 리소스에 액세스하기 위한 인증서가 필요하지만 빌드에서 생성한 최종 애플리케이션 이미지에서 해당 인증서가 사용 가능한 것은 바람직하지 않습니다. 이 목적을 위해 입력 보안을 정의할 수 있습니다.

예를 들어 Node.js 애플리케이션을 빌드할 때 Node.js 모듈에 맞게 개인용 미러를 설정할 수 있습니다. 이 개인용 미러에서 모듈을 다운로드하려면 URL, 사용자 이름 및 암호가 포함된 빌드에 사용할 사용자 정의 .npmrc 파일을 제공해야 합니다. 보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.

이 예제 시나리오를 사용하여 새 BuildConfig 오브젝트에 입력 보안을 추가할 수 있습니다.

개별적으로 제어할 수 있도록 컨테이너 이미지 관리를 설계하고 컨테이너 계층을 사용하도록 프로세스를 구축할 수 있습니다.

예를 들어, 운영 팀은 기본 이미지를 관리하는 반면 아키텍트는 미들웨어, 런타임, 데이터베이스 및 기타 솔루션을 관리합니다. 그런 다음 개발자는 애플리케이션 계층과 코드 작성에 중점을 둘 수 있습니다.

매일 새로운 취약점이 식별되므로 시간 경과에 따라 컨테이너 콘텐츠를 사전 대응식으로 확인해야 합니다. 이를 위해서는 자동화된 보안 테스트를 빌드 또는 CI 프로세스에 통합해야 합니다. 예를 들면 다음과 같습니다.

CI 프로세스에는 보안 스캔에서 발견된 문제로 빌드에 플래그를 표시하는 정책이 포함되어 있으므로, 팀이 해당 문제를 해결하기 위해 적절한 조치를 취할 수 있습니다. 빌드와 배포 사이에 아무것도 변경되지 않도록 사용자 정의 빌드 컨테이너에 서명해야 합니다.

GitOps 방법론을 사용하면 동일한 CI/CD 메커니즘을 사용하여 애플리케이션 구성뿐만 아니라 OpenShift Container Platform 인프라를 관리할 수 있습니다.

Kubernetes 및 Kourier를 사용하면 OpenShift Container Platform에서 OpenShift Serverless를 사용하여 서버리스 애플리케이션을 빌드, 배포 및 관리할 수 있습니다.

다른 빌드와 마찬가지로 S2I 이미지를 사용하여 컨테이너를 빌드한 다음 Knative 서비스를 사용하여 컨테이너를 제공할 수 있습니다. OpenShift Container Platform 웹 콘솔의 토폴로지 보기를 통해 Knative 애플리케이션 빌드를 봅니다.

빌드 프로세스 중에 문제가 발생하거나 이미지가 배포된 후 취약점이 발견되면 자동화된 정책 기반 배포 도구를 사용하여 문제를 해결할 수 있습니다. 실행 중인 컨테이너에 패치를 적용하는 것이 아니라, 트리거를 사용하여 이미지를 다시 빌드하고 교체함으로써 컨테이너 프로세스가 변경되지 않게 할 수 있습니다.

예를 들어 코어, 미들웨어 및 애플리케이션의 세 가지 컨테이너 이미지 계층을 사용하여 애플리케이션을 빌드합니다. 핵심 이미지에서 문제가 발견되고 해당 이미지가 다시 빌드됩니다. 빌드가 완료되면 이미지가 OpenShift Container Registry로 푸시됩니다. OpenShift Container Platform에서 이미지가 변경되었음을 감지하고 정의된 트리거를 기반으로 애플리케이션 이미지를 자동으로 재빌드하고 배포합니다. 이 변경은 고정 라이브러리를 통합하고 프로덕션 코드가 최신 이미지와 동일하게 합니다.

oc set triggers 명령을 사용하여 배포 트리거를 설정할 수 있습니다. 예를 들어 deployment-example이라는 배포용 트리거를 설정하려면 다음을 수행합니다.

$ oc set triggers deploy/deployment-example \
    --from-image=example:latest \
    --containers=web

원하는 이미지가 실제로 배포되고 포함된 콘텐츠를 포함하는 이미지가 신뢰할 수 있는 소스의 이미지이며 변경되지 않은 것이 중요합니다. 암호화 서명을 사용하면 이를 보장할 수 있습니다. OpenShift Container Platform을 사용하면 클러스터 관리자는 배포 환경 및 보안 요구 사항을 반영하여 광범위하거나 한정된 보안 정책을 적용할 수 있습니다. 이 정책을 정의하는 매개변수는 다음 두 가지입니다.

이러한 정책 매개변수를 사용하여 전체 레지스트리, 레지스트리 일부 또는 개별 이미지의 신뢰 관계를 허용, 거부 또는 필수로 지정할 수 있습니다. 신뢰할 수 있는 공개 키를 사용하면 암호화 방식으로 소스를 확인할 수 있습니다. 정책 규칙은 노드에 적용됩니다. 정책은 모든 노드에 균일하게 적용되거나 다른 노드 워크로드(예 : 빌드, 영역 또는 환경)를 대상으로 할 수 있습니다.

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "reject"}]
        }
    }
}

정책은 /etc/containers/policy.json으로 노드에 저장될 수 있습니다. 이 파일을 노드에 저장할 때는 새로운 MachineConfig 오브젝트를 사용하는 것이 가장 좋습니다. 이 예에서는 다음 규칙을 적용합니다.

서명 전송은 바이너리 서명 Blob을 저장하고 검색하는 방법입니다. 서명 전송의 유형은 다음 두 가지입니다.

OpenShift Container Platform API는 atomic 전송 유형을 사용하는 서명을 관리합니다. 이 서명 유형을 사용하는 이미지를 OpenShift 컨테이너 레지스트리에 저장해야 합니다. docker/distribution extensions API에서 이미지 서명 끝점을 자동 검색하므로 추가 구성이 필요하지 않습니다.

docker 전송 유형을 사용하는 서명은 로컬 파일 또는 웹 서버에서 제공합니다. 이 서명은 더 유연합니다. 컨테이너 이미지 레지스트리에서 이미지를 제공하고 독립 서버를 사용하여 바이너리 서명을 제공할 수 있습니다.

그러나 docker 전송 유형에는 추가 구성이 필요합니다. 임의로 이름이 지정된 YAML 파일을 기본적으로 호스트 시스템의 디렉터리인 /etc/containers/registries.d에 배치하여 서명 서버의 URI로 노드를 구성해야 합니다. YAML 구성 파일에는 레지스트리 URI 및 서명 서버 URI 또는 sigstore가 포함되어 있습니다.

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

이 예에서 Red Hat Registry, access.redhat.com은 docker 전송 유형의 서명을 제공하는 서명 서버입니다. 해당 URI는 sigstore 매개변수에 정의되어 있습니다. 이 파일의 이름을 /etc/containers/registries.d/redhat.com.yam로 지정하고 Machine Config Operator를 사용하여 파일을 클러스터의 각 노드에 자동으로 배치합니다. 정책 및 registries.d 파일은 컨테이너 런타임을 통해 동적으로 로드되므로 서비스를 다시 시작할 필요가 없습니다.

Secret 오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, dockercfg 파일, 개인 소스 리포지토리 인증서와 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 민감한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 시크릿을 사용하여 Pod 대신 작업을 수행할 수 있습니다.

예를 들어 개인 이미지 리포지토리에 액세스할 수 있도록 배치 구성에 보안을 추가하려면 다음을 수행하십시오.

구성 맵은 보안과 유사하지만 민감한 정보가 포함되지 않은 문자열 작업을 지원하도록 설계되었습니다. ConfigMap 오브젝트에는 Pod에서 사용하거나 컨트롤러와 같은 시스템 구성 요소의 구성 데이터를 저장하는 데 사용할 수 있는 구성 데이터의 키-값 쌍이 있습니다.

OpenShift Container Platform과 연속 배포(CD) 툴링을 통합할 수 있습니다.

CI/CD 및 OpenShift Container Platform을 활용하면 최신 수정 사항을 통합하기 위해 애플리케이션을 재빌드하고 테스트한 다음 환경 내 모든 위치에 배포되었는지 확인하는 프로세스를 자동화할 수 있습니다.

다중 테넌트를 사용하면 여러 사용자가 소유하고 여러 호스트와 네임스페이스에서 실행되는 OpenShift Container Platform 클러스터의 애플리케이션을 서로 분리하고 외부 공격으로부터 격리된 상태로 유지할 수 있습니다. 쿠버네티스 네임스페이스에 역할 기반 액세스 제어(RBAC)를 적용하여 멀티 테넌시를 확보합니다.

쿠버네티스에서 네임스페이스는 다른 애플리케이션과 분리된 방식으로 애플리케이션을 실행할 수 있는 영역입니다. OpenShift Container Platform에서는 SELinux에서 MCS 레이블링을 포함하여 주석을 추가하고 이러한 확장 네임스페이스를 프로젝트로 식별하여 네임스페이스를 사용하고 확장합니다. 프로젝트 범위 내에서 서비스 계정, 정책, 제약 조건 및 기타 다양한 오브젝트를 포함하여 자체 클러스터 리소스를 유지 관리할 수 있습니다.

선택된 사용자가 프로젝트에 액세스할 수 있도록 RBAC 오브젝트가 해당 프로젝트에 할당됩니다. 이 인증에서는 규칙, 역할 및 바인딩 양식을 사용합니다.

로컬 RBAC 역할 및 바인딩은 사용자 또는 그룹을 특정 프로젝트에 연결합니다. 클러스터 RBAC는 클러스터 전체 역할 및 바인딩을 클러스터의 모든 프로젝트에 연결할 수 있습니다. admin, basic-user, cluster-admin 및 cluster-status 액세스를 제공하기 위해 지정할 수 있는 기본 클러스터 역할이 있습니다.

RBAC는 사용자와 그룹 간의 액세스 규칙을 제어하지만 승인 플러그인 은 OpenShift Container Platform 마스터 API에 대한 액세스를 정의합니다. 승인 플러그인은 다음으로 구성된 규칙 체인을 형성합니다.

API 요청은 체인의 승인 플러그인을 통과하며 실패로 인해 요청이 거부됩니다. 각 승인 플러그인은 특정 리소스와 연결되어 있으며 해당 리소스에 대한 요청에만 응답합니다.

OpenShift Container Platform의 프레임워크에는 TLS 인증서를 통한 암호화를 활용하는 REST 기반 HTTPS 통신을 사용하는 여러 구성요소가 있습니다. OpenShift Container Platform의 설치 관리자는 설치 중에 이러한 인증서를 구성합니다. 이 트래픽을 생성하는 몇 가지 기본 구성요소가 있습니다.

OpenShift Container Platform에서는 소프트웨어 정의 네트워킹(SDN)을 사용하여 클러스터 전체의 컨테이너 간 통신이 가능한 통합 클러스터 네트워크를 제공합니다.

기본적으로 네트워크 정책 모드에서는 다른 Pod 및 네트워크 끝점에서 프로젝트의 모든 Pod에 액세스 할 수 있습니다. 프로젝트에서 하나 이상의 Pod를 분리하기 위해 해당 프로젝트에서 NetworkPolicy 오브젝트를 생성하여 수신되는 연결을 표시할 수 있습니다. 다중 테넌트 모드를 사용하면 Pod 및 서비스에 대한 프로젝트 수준 격리를 제공할 수 있습니다.

네트워크 정책을 사용하면 동일한 프로젝트에서 Pod를 서로 분리할 수 있습니다. 네트워크 정책은 Pod에 대한 모든 네트워크 액세스를 거부하거나 Ingress 컨트롤러의 연결만 허용하거나, 다른 프로젝트의 Pod의 연결을 거부하거나, 네트워크 작동 방식에 대한 유사한 규칙을 설정할 수 있습니다.

실행 중인 각 컨테이너에는 기본적으로 하나의 네트워크 인터페이스만 있습니다. Multus CNI 플러그인을 사용하면 여러 CNI 네트워크를 생성한 다음 해당 네트워크를 Pod에 연결할 수 있습니다. 이렇게 하면 개인 데이터를 더 제한된 네트워크로 분리할 수 있으며 노드마다 네트워크 인터페이스가 여러 개일 수 있습니다.

OpenShift Container Platform을 사용하면 단일 클러스터에서 네트워크 트래픽을 세그먼트화하여 사용자, 팀, 애플리케이션 및 환경을 글로벌이 아닌 리소스와 분리하는 다중 테넌트 클러스터를 만들 수 있습니다.

OpenShift Container Platform 클러스터 외부에서 쿠버네티스 서비스에 대한 액세스를 구성하는 방법과 관련하여 보안에 미치는 영향이 많이 있습니다. HTTP 및 HTTPS 경로를 노출하는 외에도 수신 라우팅을 사용하면 NodePort 또는 LoadBalancer 수신 유형을 설정할 수 있습니다. NodePort에서는 각 클러스터 작업자의 애플리케이션 서비스 API 오브젝트를 노출합니다. LoadBalancer를 사용하면 OpenShift Container Platform 클러스터의 관련 서비스 API 오브젝트에 외부 로드 밸런서를 할당할 수 있습니다.

OpenShift Container Platform에서는 라우터 또는 방화벽 방법을 사용하여 송신 트래픽을 제어하는 기능을 제공합니다. 예를 들어 IP 화이트리스트를 사용하여 데이터베이스 액세스를 제어할 수 있습니다. 클러스터 관리자는 OpenShift Container Platform SDN 네트워크 공급자의 프로젝트에 하나 이상의 송신 IP 주소를 할당할 수 있습니다. 마찬가지로 클러스터 관리자는 송신 방화벽을 사용하여 송신 트래픽이 OpenShift Container Platform 클러스터 외부로 나가는 것을 방지할 수 있습니다.

고정 송신 IP 주소를 할당하면 특정 프로젝트용으로 나가는 모든 트래픽을 해당 IP 주소에 할당할 수 있습니다. 송신 방화벽을 사용하면 Pod가 외부 네트워크에 연결 또는 Pod가 내부 네트워크에 연결하는 것을 방지하거나 특정 내부 서브넷에 대한 Pod의 액세스를 제한할 수 있습니다.

컨테이너는 스테이트리스(stateless) 및 스테이트풀(stateful) 애플리케이션 둘 다에 유용합니다. 연결된 스토리지를 보호하는 것이 상태 저장 서비스 보안의 핵심 요소입니다. CSI(Container Storage Interface)를 사용하여 OpenShift Container Platform에서는 CSI 인터페이스를 지원하는 모든 스토리지 백엔드의 스토리지를 통합할 수 있습니다.

OpenShift Container Platform은 다음을 포함하여 여러 유형의 스토리지에 대한 플러그인을 제공합니다.

동적 프로비저닝이 있는 스토리지 유형의 플러그인은 별표(*)로 표시됩니다. 서로 통신 중인 모든 OpenShift Container Platform 구성요소에서 전송 중인 데이터는 HTTPS를 통해 암호화됩니다.

스토리지 유형에서 지원하는 방식으로 호스트에 영구 볼륨(PV)을 마운트할 수 있습니다. 스토리지 유형에 따라 기능이 다르며 각 PV의 액세스 모드는 해당 볼륨에서 지원하는 특정 모드로 설정됩니다.

예를 들어 NFS에서는 여러 읽기/쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로 내보낼 수 있습니다. 각 PV에는 ReadWriteOnce, ReadOnlyMany 및 ReadWriteMany와 같은 특정 PV 기능을 설명하는 자체 액세스 모드 세트가 있습니다.

NFS와 같은 공유 스토리지 공급자의 경우 PV는 그룹 ID(GID)를 PV 리소스에 대한 주석으로 등록합니다. 그런 다음 Pod에서 PV를 요청하면 주석이 달린 GID가 Pod의 보충 그룹에 추가되므로, 해당 Pod가 공유 스토리지의 콘텐츠에 액세스할 수 있습니다.

AWS EBS(Elastic Block Store), GCE 영구 디스크 및 iSCSI와 같은 블록 스토리지 공급자의 경우 OpenShift Container Platform에서는 SELinux 기능을 사용하여 권한이 없는 Pod용으로 마운트된 볼륨의 루트를 보호함으로써, 연관된 컨테이너에서만 마운트된 볼륨을 소유하고 볼 수 있게 합니다.

클러스터 관리자는 Event 리소스 유형을 익히고 시스템 이벤트 목록을 검토하여 관심있는 이벤트를 결정하는 것이 좋습니다. 이벤트는 네임스페이스, 즉 관련 리소스의 네임스페이스 또는 클러스터 이벤트의 경우에는 default 네임스페이스와 연결됩니다. 기본 네임스페이스에는 인프라 구성요소와 관련된 노드 이벤트 및 리소스 이벤트와 같은 클러스터 모니터링 또는 감사 관련 이벤트가 있습니다.

마스터 API 및 oc 명령은 이벤트 목록의 범위를 노드 관련 항목으로만 지정하는 매개변수는 제공하지 않습니다. 간단한 접근 방식은 grep을 사용하는 것입니다.

$ oc get event -n default | grep Node

1h         20h         3         origin-node-1.example.local   Node      Normal    NodeHasDiskPressure   ...

더 유연한 접근 방식은 다른 툴에서 처리할 수 있는 양식으로 이벤트를 출력하는 것입니다. 예를 들어 다음 예에서는 JSON 출력을 대상으로 jq 툴을 사용하여 NodeHasDiskPressure 이벤트만 추출합니다.

$ oc get events -n default -o json \
  | jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'

{
  "apiVersion": "v1",
  "count": 3,
  "involvedObject": {
    "kind": "Node",
    "name": "origin-node-1.example.local",
    "uid": "origin-node-1.example.local"
  },
  "kind": "Event",
  "reason": "NodeHasDiskPressure",
  ...
}

리소스 생성, 수정 또는 삭제와 관련된 이벤트도 클러스터의 오용을 탐지하는 데 적합할 수 있습니다. 예를 들어 다음과 같은 쿼리를 사용하면 과도한 이미지 가져오기를 찾을 수 있습니다.

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'

4

oc log 명령을 사용하면 컨테이너 로그, 빌드 구성, 배포를 실시간으로 볼 수 있습니다. 다른 사용자는 다른 로그에 액세스할 수 있습니다.

추가 감사 및 분석을 위해 로그를 저장하려면 cluster-logging 애드온 기능을 사용하여 시스템, 컨테이너 및 감사 로그를 수집, 관리 및 볼 수 있습니다. OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 통해 OpenShift Logging을 배포, 관리 및 업그레이드할 수 있습니다.

감사 로그를 사용하면 사용자, 관리자 또는 기타 OpenShift Container Platform 구성요소의 동작과 관련된 일련의 활동을 따를 수 있습니다. API 감사 로깅은 각 서버에서 수행됩니다.

기본적으로 OpenShift Container Platform에서는 Ingress Operator를 사용하여 내부 CA를 생성하고 .apps 하위 도메인의 애플리케이션에 유효한 와일드카드 인증서를 발급합니다. 웹 콘솔과 CLI도 모두 이 인증서를 사용합니다.

내부 인프라 CA 인증서는 자체 서명됩니다. 이 프로세스는 일부 보안 또는 PKI 팀에서는 나쁜 습관으로 인식할 수 있지만 위험이 거의 없습니다. 이러한 인증서를 암시적으로 신뢰하는 유일한 클라이언트는 클러스터 내의 다른 구성요소입니다. 기본 와일드카드 인증서를 컨테이너 사용자 공간에서 제공한 대로 이미 CA 번들에 포함된 공용 CA에서 발행한 인증서로 교체하면 외부 클라이언트가 .apps 하위 도메인에서 실행되는 애플리케이션에 안전하게 연결할 수 있습니다.

.apps 하위 도메인에 있는 애플리케이션의 기본 수신 인증서를 교체할 수 있습니다. 인증서를 교체하고 나면 웹 콘솔 및 CLI를 포함한 모든 애플리케이션에는 지정된 인증서에서 제공하는 암호화가 생깁니다.

추가 리소스

기본 API 서버 인증서는 내부 OpenShift Container Platform 클러스터 CA에서 발급합니다. 리버스 프록시 또는 로드 밸런서가 사용되는 경우와 같이 클라이언트가 요청한 정규화된 도메인 이름(FQDN)을 기반으로 API 서버가 반환할 대체 인증서를 하나 이상 추가할 수 있습니다.

서비스 제공 인증서는 암호화가 필요한 복잡한 미들웨어 애플리케이션을 지원하기 위한 것입니다. 이러한 인증서는 TLS 웹 서버 인증서로 발급됩니다.

service-ca 컨트롤러에서는 x509.SHA256WithRSA 서명 알고리즘을 사용하여 서비스 인증서를 생성합니다.

생성된 인증서 및 키는 PEM 형식이며, 생성된 보안의 tls.crt 및 tls.key에 각각 저장됩니다. 인증서와 키는 만료 시기가 다가오면 자동으로 교체됩니다.

서비스 인증서를 발급하는 서비스 CA 인증서는 26개월 동안 유효하며 유효 기간이 13개월 미만으로 남아 있으면 자동으로 순환됩니다. 교체 후에도 이전 서비스 CA 구성은 만료될 때까지 계속 신뢰 상태가 유지됩니다. 그러면 만료되기 전에 유예 기간 동안 영향을 받는 모든 서비스의 주요 자료를 새로 고칠 수 있습니다. 서비스를 다시 시작하고 키 자료를 새로 고치는 이 유예 기간 동안 클러스터를 업그레이드하지 않으면 이전 서비스 CA가 만료된 후 실패하지 않도록 서비스를 직접 다시 시작해야 할 수도 있습니다.

$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
      do oc delete pods --all -n $I; \
      sleep 1; \
      done

서비스와의 통신을 보호하려면 서명된 제공 인증서와 키 쌍을 서비스와 동일한 네임스페이스의 보안에 생성합니다.

생성된 인증서는 내부 서비스 DNS 이름 <service.name>.<service.namespace>.svc에만 유효하고 내부 통신에만 유효합니다. 서비스가 헤드리스 서비스(clusterIP 값이 설정되지 않음)인 경우 생성된 인증서에는 *.<service.name>.<service.namespace>.svc 형식의 와일드카드 제목도 포함됩니다.

Pod는 service.beta.openshift.io/inject-cabundle=true 로 주석이 달린 ConfigMap 오브젝트를 마운트하여 서비스 CA 인증서에 액세스할 수 있습니다. 주석이 달리면 클러스터에서 서비스 CA 인증서를 구성 맵의 service-ca.crt 키에 자동으로 삽입합니다. 이 CA 인증서에 액세스하면 TLS 클라이언트가 서비스 제공 인증서를 사용하여 서비스에 대한 연결을 확인할 수 있습니다.

spec.caBundle 필드에 서비스 CA 번들이 입력되도록 service.beta.openshift.io/inject-cabundle=true로 APIService 오브젝트에 주석을 답니다. 그러면 쿠버네티스 API 서버가 대상 끝점을 보호하는 데 사용되는 서비스 CA 인증서의 유효성을 확인할 수 있습니다.

spec.conversion.webhook.clientConfig.caBundle 필드에 서비스 CA 번들이 입력되도록 CustomResourceDefinition(CRD) 오브젝트에 service.beta.openshift.io/inject-cabundle=true로 주석을 답니다. 그러면 쿠버네티스 API 서버가 대상 끝점을 보호하는 데 사용되는 서비스 CA 인증서의 유효성을 확인할 수 있습니다.

각 웹 후크의 clientConfig.caBundle 필드에 서비스 CA 번들이 입력되도록 service.beta.openshift.io/inject-cabundle=true로 MutatingWebhookConfiguration 오브젝트에 주석을 달 수 있습니다. 그러면 쿠버네티스 API 서버가 대상 끝점을 보호하는 데 사용되는 서비스 CA 인증서의 유효성을 확인할 수 있습니다.

각 웹 후크의 clientConfig.caBundle 필드에 서비스 CA 번들이 입력되도록 service.beta.openshift.io/inject-cabundle=true로 ValidatingWebhookConfiguration 오브젝트에 주석을 달 수 있습니다. 그러면 쿠버네티스 API 서버가 대상 끝점을 보호하는 데 사용되는 서비스 CA 인증서의 유효성을 확인할 수 있습니다.

관련 보안을 삭제하여 서비스 인증서를 순환할 수 있습니다. 보안을 삭제하면 새로운 보안이 자동으로 생성되어 새 인증서가 생성됩니다.

서비스 CA는 26개월 동안 유효하며 유효 기간이 13개월 미만으로 남아 있으면 자동으로 새로 고쳐집니다.

필요하면 다음 절차에 따라 서비스 CA를 직접 새로 고칠 수 있습니다.

프록시 인증서를 사용하면 송신 연결을 수행할 때 플랫폼 구성 요소에서 사용하는 하나 이상의 사용자 정의 인증 기관(CA)을 지정할 수 있습니다.

Proxy 오브젝트의 trustedCA 필드는 사용자 제공 신뢰할 수 있는 인증 기관(CA) 번들을 포함하는 구성 맵에 대한 참조입니다. 이 번들은 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들과 병합되어 송신 HTTPS 호출을 수행하는 플랫폼 구성요소의 신뢰 저장소에 삽입됩니다. 예를 들어 image-registry-operator에서 이미지를 다운로드하도록 외부 이미지 레지스트리를 호출합니다. trustedCA를 지정하지 않으면 프록시 HTTPS 연결에 RHCOS 신뢰 번들만 사용됩니다. 자체 인증서 인프라를 사용하려면 RHCOS 신뢰 번들에 사용자 정의 CA 인증서를 제공합니다.

trustedCA 필드는 프록시 유효성 검증기만 사용해야 합니다. 유효성 검증기를 통해서는 필수 키 ca-bundle.crt에서 인증서 번들을 읽고 openshift-config-managed 네임스페이스의 trusted-ca-bundle이라는 구성 맵에 복사해야 합니다. trustedCA에서 참조하는 구성 맵의 네임스페이스는 openshift-config입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----

추가 리소스

API 서버는 api.<cluster_name>.<base_domain>에서 클러스터 외부의 클라이언트가 액세스할 수 있습니다. 클라이언트가 다른 호스트 이름으로 또는 클러스터 관리 인증 기관(CA) 인증서를 클라이언트에 배포하지 않고 API 서버에 액세스하게 합니다. 관리자는 콘텐츠를 제공할 때 API 서버가 사용할 사용자 정의 기본 인증서를 설정해야 합니다.

사용자 제공 인증서는 openshift-config 네임스페이스에 kubernetes.io/tls 유형 Secret으로 제공되어야 합니다. API 서버 클러스터 구성인 apiserver/cluster 리소스를 업데이트하여 사용자 제공 인증서를 사용할 수 있게 합니다.

사용자 제공 인증서는 사용자가 관리합니다.

API 서버 클라이언트 인증서가 5분 내에 만료됩니다.

사용자 제공 인증서는 사용자가 관리합니다.

필요에 따라 사용자 관리 인증서가 포함된 보안을 업데이트합니다.

추가 리소스

프록시 인증서를 사용하면 송신 연결을 만들 때 플랫폼 구성요소에서 사용하는 하나 이상의 사용자 정의 인증 기관(CA) 인증서를 지정할 수 있습니다.

Proxy 오브젝트의 trustedCA 필드는 사용자 제공 신뢰할 수 있는 인증 기관(CA) 번들을 포함하는 구성 맵에 대한 참조입니다. 이 번들은 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들과 병합되어 송신 HTTPS 호출을 수행하는 플랫폼 구성요소의 신뢰 저장소에 삽입됩니다. 예를 들어 image-registry-operator에서 이미지를 다운로드하도록 외부 이미지 레지스트리를 호출합니다. trustedCA를 지정하지 않으면 프록시 HTTPS 연결에 RHCOS 신뢰 번들만 사용됩니다. 자체 인증서 인프라를 사용하려면 RHCOS 신뢰 번들에 사용자 정의 CA 인증서를 제공합니다.

trustedCA 필드는 프록시 유효성 검증기만 사용해야 합니다. 유효성 검증기를 통해서는 필수 키 ca-bundle.crt에서 인증서 번들을 읽고 openshift-config-managed 네임스페이스의 trusted-ca-bundle이라는 구성 맵에 복사해야 합니다. trustedCA에서 참조하는 구성 맵의 네임스페이스는 openshift-config입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----

추가 리소스

설치 프로그램 구성의 additionalTrustBundle 값은 설치 중 프록시 신뢰 CA 인증서를 지정하는 데 사용됩니다. 예를 들면 다음과 같습니다.

$ cat install-config.yaml

...
proxy:
  httpProxy: http://<username:password@proxy.example.com:123/>
  httpsProxy: http://<username:password@proxy.example.com:123/>
  noProxy: <123.example.com,10.88.0.0/16>
additionalTrustBundle: |
    -----BEGIN CERTIFICATE-----
   <MY_HTTPS_PROXY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
...

사용자 제공 신뢰 번들은 구성 맵으로 표시됩니다. 구성 맵은 송신 HTTPS 호출을 수행하는 플랫폼 구성 요소의 파일 시스템에 마운트됩니다. 일반적으로 Operator는 구성 맵을 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem에 마운트하지만 프록시에는 필요하지 않습니다. 프록시는 HTTPS 연결을 수정하거나 검사할 수 있습니다. 두 경우 모두 프록시는 연결을 위해 새 인증서를 생성하고 서명해야 합니다.

완전한 프록시 지원이란 지정된 프록시에 연결하고 생성된 서명을 신뢰한다는 의미입니다. 따라서 사용자가 신뢰할 수 있는 루트를 지정하고 이 신뢰할 수 있는 루트에 연결된 인증서 체인도 신뢰할 수 있게 해야 합니다.

RHCOS 신뢰 번들을 사용하는 경우 /etc/pki/ca-trust/source/anchors에 CA 인증서를 둡니다.

자세한 정보는 Red Hat Enterprise Linux 설명서에서 공유 시스템 인증서 사용을 참조하십시오.

사용자가 사용자 제공 신뢰 번들의 만료 기간을 설정합니다.

기본 만료 기간은 CA 인증서 자체를 통해 정의됩니다. OpenShift Container Platform 또는 RHCOS에서 사용하기 전에 인증서에 맞게 기본 만료 기간을 구성하는 것은 CA 관리자의 책임입니다.

기본적으로 송신 HTTPS 호출을 수행하는 모든 플랫폼 구성요소에서는 RHCOS 신뢰 번들을 사용합니다. trustedCA가 정의된 경우에도 사용됩니다.

RHCOS 노드에서 실행 중인 모든 서비스는 노드의 신뢰 번들을 사용할 수 있습니다.

이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.

사용자 제공 신뢰 번들 업데이트는 다음 중 하나로 구성됩니다.

RHCOS 신뢰 번들에 CA 인증서를 작성하는 메커니즘은 다른 파일을 RHCOS에 작성하는 방법과 같습니다. 이 방법은 머신 구성을 사용하여 수행됩니다. MCO(Machine Config Operator)에서 새 CA 인증서가 포함된 새 머신 구성을 적용하면 나중에 프로그램 update-ca-trust 를 실행하고 RHCOS 노드에서 CRI-O 서비스를 다시 시작합니다. 이번 업데이트에서는 노드를 재부팅할 필요가 없습니다. CRI-O 서비스를 다시 시작하면 새 CA 인증서로 신뢰 번들이 자동으로 업데이트됩니다. 예를 들면 다음과 같습니다.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-examplecorp-ca-cert
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        mode: 0644
        overwrite: true
        path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt

머신의 신뢰 저장소는 노드의 신뢰 저장소 업데이트도 지원해야 합니다.

RHCOS 노드에서 인증서를 자동 갱신할 수 있는 Operator가 없습니다.

service-ca는 OpenShift Container Platform 클러스터가 배포될 때 자체 서명된 CA를 만드는 Operator입니다.

사용자 정의 기간은 지원되지 않습니다. 자체 서명된 CA는 tls.crt(인증서), tls.key(개인 키) 및 ca-bundle.crt(CA 번들)의 규정된 이름 service-ca/signing-key로 보안에 저장됩니다.

다른 서비스에서는 service.beta.openshift.io/serving-cert-secret-name: <secret name>으로 서비스 리소스에 주석을 달아 서비스 제공 인증서를 요청할 수 있습니다. 이에 응답하여 Operator는 이름 지정된 보안에 대한 tls.crt로 새 인증서를, tls.key로 개인 키를 생성합니다. 이 인증서는 2년간 유효합니다.

다른 서비스에서는 서비스 CA에서 생성된 인증서의 검증을 지원하기 위해 service.beta.openshift.io/inject-cabundle: true로 주석을 달아 서비스 CA의 CA 번들을 API 서비스 또는 구성 맵 리소스에 삽입하도록 요청할 수 있습니다. 이에 응답하여 Operator는 현재 CA 번들을 API 서비스의 CABundle 필드에 쓰거나 service-ca.crt로 구성 맵에 씁니다.

OpenShift Container Platform 4.3.5부터 자동 순환이 지원되며 일부 4.2.z 및 4.3.z 릴리스로 백포트됩니다. 자동 순환을 지원하는 모든 릴리스에서 서비스 CA는 26개월 동안 유효하며 유효 기간이 13개월 미만으로 남아 있으면 자동으로 새로 고칩니다. 필요하면 서비스 CA를 직접 새로 고칠 수 있습니다.

26개월의 서비스 CA 만료 기간은 지원되는 OpenShift Container Platform 클러스터에 대한 업그레이드 예상 간격보다 길기 때문에 서비스 CA 인증서의 비컨트롤 플레인 소비자의 CA는 CA 순환 후와 순환 전 CA 만료 전에 새로 고칩니다.

이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.

서비스 CA 인증서를 사용하는 서비스는 다음과 같습니다.

이것은 포괄적인 목록이 아닙니다.

추가 리소스

노드 인증서는 클러스터에서 서명하고 kubelet이 Kubernetes API 서버와 통신할 수 있도록 합니다. 이러한 인증서는 부트스트랩 프로세스에서 생성되는 kubelet CA 인증서에서 가져옵니다.

kubelet CA 인증서는 openshift-kube-apiserver-operator 네임스페이스의 kube-apiserver-to-kubelet-signer 시크릿에 있습니다.

이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.

노드 인증서는 292일 후에 자동으로 교체되고 365일 후에 만료됩니다.

Kubernetes API Server Operator는 292일 내에 새 kube-apiserver-to-kubelet-signer CA 인증서를 자동으로 생성합니다. 이전 CA 인증서는 365일 후에 제거됩니다. kubelet CA 인증서가 업데이트되거나 제거되면 노드가 재부팅되지 않습니다.

클러스터 관리자는 다음 명령을 실행하여 kubelet CA 인증서를 수동으로 갱신할 수 있습니다.

$ oc annotate -n openshift-kube-apiserver-operator secret kube-apiserver-to-kubelet-signer auth.openshift.io/certificate-not-after-

추가 리소스

OpenShift Container Platform 4 이상에서 kubelet은 /etc/kubernetes/kubeconfig에 있는 부트스트랩 인증서를 사용하여 처음에 부트스트랩합니다. 그런 다음 부트스트랩 초기화 프로세스 및 CSR을 생성하기 위한 kubelet 권한 부여가 이어집니다.

이 과정에서 kubelet은 부트스트랩 채널을 통해 통신하면서 CSR을 생성합니다. 컨트롤러 관리자는 CSR에 서명하여 kubelet을 통해 관리하는 인증서를 생성합니다.

이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.

이 부트스트랩 인증서는 10년 동안 유효합니다.

kubelet 관리형 인증서는 1년 동안 유효하며 1년 중 80% 정도되는 시점에 자동으로 순환됩니다.

부트스트랩 인증서를 사용자 정의할 수 없습니다.

etcd 인증서는 etcd-signer를 통해 서명합니다. 노드 인증서는 부트스트랩 프로세스를 통해 생성된 인증 기관(CA)에서 제공합니다.

CA 인증서는 10년 동안 유효합니다. 피어, 클라이언트 및 서버 인증서는 3년간 유효합니다.

만료되기 전에 etcd 인증서를 순환합니다.

다음 두 가지 경고 유형은 보류 중인 etcd 인증서 만료에 대해 알려줍니다.

다음과 같은 이유로 인증서를 순환할 수 있습니다.

OpenShift Container Platform 메트릭 시스템에는 etcd 서명자가 있습니다. etcd 인증서를 Rotating할 때 다음 지표 매개변수를 대체합니다.

이러한 인증서는 시스템에서만 관리되며 자동으로 교체됩니다.

etcd 인증서는 etcd 멤버 피어와 암호화된 클라이언트 트래픽 간의 암호화된 통신에 사용됩니다. 다음 인증서는 etcd 및 etcd와 통신하는 다른 프로세스를 통해 생성되고 사용됩니다.

추가 리소스

OLM(Operator Lifecycle Manager) 구성 요소(olm-operator,catalog-operator,packageserver, marketplace-operator)에 대한 모든 인증서는 시스템에서 관리합니다.

CSV(ClusterServiceVersion) 개체에 Webhook 또는 API 서비스가 포함된 Operator를 설치하면 OLM이 이러한 리소스의 인증서를 생성하고 회전합니다. openshift-operator-lifecycle-manager 네임스페이스의 리소스의 인증서는 OLM에서 관리합니다.

OLM은 프록시 환경에서 관리하는 Operator의 인증서를 업데이트하지 않습니다. 이러한 인증서는 서브스크립션 구성을 통해 사용자가 관리해야 합니다.

집계된 API 클라이언트 인증서는 집계된 API 서버에 연결할 때 KubeAPIServer를 인증하는 데 사용됩니다.

이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.

이 CA는 30일 동안 유효합니다.

관리형 클라이언트 인증서는 30일 동안 유효합니다.

CA 및 클라이언트 인증서는 컨트롤러를 사용하여 자동으로 순환됩니다.

집계된 API 서버 인증서를 사용자 지정할 수 없습니다.

이 인증 기관은 초기 프로비저닝 중에 노드에서 MCS(Machine Config Server)로의 연결을 보호하는 데 사용됩니다.

두 개의 인증서가 있습니다. . 자체 서명된 CA, MCS CA . 파생 인증서, MCS 인증서

현재 이러한 인증서 중 하나를 직접 수정하는 것은 지원되지 않습니다.

MCS CA는 10년 동안 유효합니다.

발급된 제공 인증서는 10년 동안 유효합니다.

Machine Config Operator 인증서를 사용자 지정할 수 없습니다.

애플리케이션은 일반적으로 <route_name>.apps.<cluster_name>.<base_domain>에서 노출됩니다. <cluster_name> 및 <base_domain>은 설치 구성 파일에서 가져옵니다. <route_name>은 경로가 지정된 경우 경로의 호스트 필드이거나 경로 이름입니다. 예를 들면 hello-openshift-default.apps.username.devcluster.openshift.com입니다. hello-openshift는 경로의 이름이고 경로는 기본 네임스페이스에 있습니다. 클러스터 관리 CA 인증서를 클라이언트에 배포할 필요없이 클라이언트가 애플리케이션에 액세스하게 합니다. 애플리케이션 콘텐츠를 제공할 때 관리자는 사용자 정의 기본 인증서를 설정해야 합니다.

사용자 제공 인증서는 openshift-ingress 네임스페이스에 tls 유형 Secret 리소스로 제공되어야 합니다. 사용자 제공 인증서를 사용할 수 있도록 openshift-ingress-operator 네임스페이스에서 IngressController CR을 업데이트합니다. 이 프로세스에 대한 자세한 내용은 사용자 정의 기본 인증서 설정을 참조하십시오.

사용자 제공 인증서는 사용자가 관리합니다.

사용자 제공 인증서는 사용자가 관리합니다.

클러스터에 배포된 애플리케이션에서는 기본 수신에 사용자 제공 인증서를 사용합니다.

필요에 따라 사용자 관리 인증서가 포함된 보안을 업데이트합니다.

추가 리소스

Ingress Operator에서는 다음을 위해 인증서를 사용합니다.

Ingress Operator 및 Ingress Controller 지표에 대한 액세스를 보호하기 위해 Ingress Operator에서는 서비스 제공 인증서를 사용합니다. Operator가 service-ca 컨트롤러에서 고유 지표에 맞는 인증서를 요청하고, service-ca 컨트롤러가 metrics-tls라는 보안의 인증서를 openshift-ingress-operator 네임스페이스에 둡니다. 또한 Ingress Operator에서 각 Ingress Controller의 인증서를 요청하고 service-ca 컨트롤러에서 router-metrics-certs-<name>라는 보안에 인증서를 넣습니다. 여기서 <name>은 openshift-ingress 네임스페이스의 Ingress Controller의 이름입니다.

각 Ingress Controller에는 고유 인증서를 지정하지 않는 보안 경로에 사용하는 기본 인증서가 있습니다. 사용자 정의 인증서를 지정하지 않으면 Operator에서 기본적으로 자체 서명된 인증서를 사용합니다. Operator는 자체 서명된 서명 인증서를 사용하여 생성하는 기본 인증서에 서명합니다. Operator는 이 서명 인증서를 생성하여 openshift-ingress-operator 네임스페이스의 router-ca라는 보안에 둡니다. Operator가 기본 인증서를 생성하고 openshift-ingress 네임스페이스의 router-certs-<name>라는 보안에 기본 인증서를 둡니다(여기서 <name>은 Ingress Controller의 이름임).

defaultCertificate 필드가 비어 있으면 Ingress Operator에서 자체 서명된 CA를 사용하여 지정된 도메인의 제공 인증서를 생성합니다.

Ingress Operator에서 생성한 기본 CA 인증서 및 키. Operator 생성 기본 제공 인증서에 서명하는 데 사용합니다.

기본 워크플로에서는 Ingress Operator가 작성하고 생성된 기본 CA 인증서를 사용하여 서명한 와일드카드 기본 제공 인증서입니다. 사용자 정의 워크플로에서 이 인증서는 사용자 제공 인증서입니다.

라우터 배포. secrets/router-certs-default의 인증서를 기본 프론트 엔드 서버 인증서로 사용합니다.

기본 워크플로에서 와일드카드 기본 제공 인증서(공용 및 개인용 부분)의 콘텐츠가 여기에 복사되므로 OAuth 통합이 가능합니다. 사용자 정의 워크플로에서 이 인증서는 사용자 제공 인증서입니다.

기본 제공 인증서의 공용(인증서) 부분입니다. configmaps/router-ca 리소스를 교체합니다.

사용자는 ingresscontroller 제공 인증서에 서명한 CA 인증서로 클러스터 프록시 구성을 업데이트합니다. 그러면 auth, console 및 레지스트리와 같은 구성요소가 제공 인증서를 신뢰할 수 있습니다.

사용자 번들이 제공되지 않은 경우 RHCOS(Red Hat Enterprise Linux CoreOS) 및 사용자 제공 CA 번들 또는 RHCOS 전용 번들을 포함하는 클러스터 전체의 신뢰할 수 있는 CA 번들입니다.

사용자 정의 인증서로 구성된 ingresscontroller를 신뢰하도록 다르 구성요소(예: auth 및 console)에 지시하는 사용자 정의 CA 인증서 번들입니다.

trustedCA 필드는 사용자 제공 CA 번들을 참조하는 데 사용됩니다.

Cluster Network Operator에서 신뢰할 수 있는 CA 번들을 proxy-ca 구성 맵에 삽입합니다.

OpenShift Container Platform 4.16 이상에서는 default-ingress-cert 를 사용합니다.

Ingress Operator 인증서의 만료 기간은 다음과 같습니다.

Ingress Operator 또는 service-ca 컨트롤러에서 생성하는 인증서에 사용자 정의 만료 기간을 지정할 수 없습니다.

Ingress Operator 또는 Service-CA 컨트롤러가 생성하는 인증서에 맞게 OpenShift Container Platform을 설치하면 만료 조건을 지정할 수 없습니다.

Prometheus에서는 메트릭을 보호하는 인증서를 사용합니다.

Ingress Operator에서는 서명 인증서를 사용하여 사용자 정의 기본 인증서를 설정하지 않은 Ingress Controller용으로 생성한 기본 인증서에 서명합니다.

보안 경로를 사용하는 클러스터 구성요소는 기본 Ingress Controller의 기본 인증서를 사용할 수 있습니다.

보안 경로를 통해 클러스터로 수신할 때는 경로에서 고유 인증서를 지정하지 않는 한 경로에 액세스하는 Ingress Controller의 기본 인증서를 사용합니다.

수신 인증서는 사용자가 관리합니다. 자세한 내용은 기본 수신 인증서 교체 를 참조하십시오.

service-ca 컨트롤러에서는 발급한 인증서가 자동으로 순환됩니다. 그러나 oc delete secret <secret>을 사용하여 서비스 제공 인증서를 직접 순환할 수 있습니다.

Ingress Operator에서는 자체 서명 인증서 또는 생성된 기본 인증서가 순환되지 않습니다. Operator가 생성한 기본 인증서는 구성하는 사용자 정의 기본 인증서의 자리 표시자로 사용됩니다.

모니터링 구성요소는 서비스 CA 인증서로 트래픽을 보호합니다. 이 인증서는 2년 동안 유효하며 서비스 CA 순환 시 13개월마다 자동으로 교체됩니다.

인증서가 openshift-monitoring 또는 openshift-logging 네임스페이스에 있으면 시스템 관리 및 순환이 자동으로 이루어집니다.

이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.

컨트롤 플레인 인증서는 다음 네임스페이스에 포함되어 있습니다.

컨트롤 플레인 인증서는 시스템에서 관리하고 자동으로 순환됩니다.

드문 경우지만 컨트롤 플레인 인증서가 만료된 경우 만료된 컨트롤 플레인 인증서에서 복구를 참조하십시오.

OpenShift Compliance Operator 1.6.1에 대해 다음 권고를 사용할 수 있습니다.

이번 업데이트에서는 기본 기본 이미지의 업그레이드된 종속 항목이 포함되어 있습니다.

OpenShift Compliance Operator 1.6.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.5.1에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.5.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.4.1에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.4.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.3.1에 대해 다음 권고를 사용할 수 있습니다.

이번 업데이트에서는 기본 종속성의 CVE를 해결합니다.

OpenShift Compliance Operator 1.3.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.2.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.1.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 1.0.0에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.61에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.59에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.57에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.53에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.52에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.49에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.48에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.47에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.44에 대해 다음 권고를 사용할 수 있습니다.

OpenShift Compliance Operator 0.1.39에 대해 다음 권고를 사용할 수 있습니다.

Compliance Operator는 "Rolling Stream" Operator입니다. 즉, OpenShift Container Platform 릴리스의 비동기식으로 업데이트를 사용할 수 있습니다. 자세한 내용은 Red Hat Customer Portal의 OpenShift Operator 라이프 사이클 을 참조하십시오.

이 문서에 설명된 절차 또는 일반적으로 OpenShift Container Platform에 문제가 발생하는 경우 Red Hat 고객 포털에 액세스하십시오.

고객 포털에서 다음을 수행할 수 있습니다.

클러스터 문제를 식별하기 위해 OpenShift Cluster Manager 에서 Insights를 사용할 수 있습니다. Insights는 문제에 대한 세부 정보 및 문제 해결 방법에 대한 정보를 제공합니다.

이 문서를 개선하기 위한 제안이 있거나 오류를 발견한 경우 가장 관련 문서 구성 요소에 대해 Jira 문제를 제출합니다. 섹션 이름 및 OpenShift Container Platform 버전과 같은 구체적인 정보를 제공합니다.

Compliance Operator v1.6.0부터 Compliance Operator 이미지로 must-gather 명령을 실행하여 Compliance Operator 리소스에 대한 데이터를 수집할 수 있습니다.

OpenShift Container Platform 관리자는 Compliance Operator를 통해 클러스터의 필수 규정 준수 상태를 설명하고 격차에 대한 개요와 문제를 해결하는 방법을 제공할 수 있습니다. Compliance Operator는 OpenShift Container Platform의 Kubernetes API 리소스와 클러스터를 실행하는 노드 모두의 규정 준수를 평가합니다. Compliance Operator는 NIST 인증 툴인 OpenSCAP을 사용하여 콘텐츠에서 제공하는 보안 정책을 검사하고 시행합니다.

OpenShift Container Platform의 Compliance Operator는 규정 준수 검사를 수행할 수 있도록 여러 CRD(Custom Resource Definitions)를 제공합니다. 규정 준수 검사를 실행하기 위해 ComplianceAsCode 커뮤니티 프로젝트에서 파생되는 사전 정의된 보안 정책을 활용합니다. Compliance Operator는 이러한 보안 정책을 CRD로 변환하여 규정 준수 검사를 실행하고 발견된 문제에 대한 수정을 받을 수 있습니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
  name: <profile bundle name>
  namespace: openshift-compliance
status:
  dataStreamStatus: VALID 1

apiVersion: compliance.openshift.io/v1alpha1
description: <description of the profile>
id: xccdf_org.ssgproject.content_profile_moderate 1
kind: Profile
metadata:
  annotations:
    compliance.openshift.io/product: <product name>
    compliance.openshift.io/product-type: Node 2
  creationTimestamp: "YYYY-MM-DDTMM:HH:SSZ"
  generation: 1
  labels:
    compliance.openshift.io/profile-bundle: <profile bundle name>
  name: rhcos4-moderate
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: <profile bundle name>
    uid: <uid string>
  resourceVersion: "<version number>"
  selfLink: /apis/compliance.openshift.io/v1alpha1/namespaces/openshift-compliance/profiles/rhcos4-moderate
  uid: <uid string>
rules: 3
- rhcos4-account-disable-post-pw-expiration
- rhcos4-accounts-no-uid-except-zero
- rhcos4-audit-rules-dac-modification-chmod
- rhcos4-audit-rules-dac-modification-chown
title: <title of the profile>

    apiVersion: compliance.openshift.io/v1alpha1
    checkType: Platform 1
    description: <description of the rule>
    id: xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces 2
    instructions: <manual instructions for the scan>
    kind: Rule
    metadata:
      annotations:
        compliance.openshift.io/rule: configure-network-policies-namespaces
        control.compliance.openshift.io/CIS-OCP: 5.3.2
        control.compliance.openshift.io/NERC-CIP: CIP-003-3 R4;CIP-003-3 R4.2;CIP-003-3
          R5;CIP-003-3 R6;CIP-004-3 R2.2.4;CIP-004-3 R3;CIP-007-3 R2;CIP-007-3 R2.1;CIP-007-3
          R2.2;CIP-007-3 R2.3;CIP-007-3 R5.1;CIP-007-3 R6.1
        control.compliance.openshift.io/NIST-800-53: AC-4;AC-4(21);CA-3(5);CM-6;CM-6(1);CM-7;CM-7(1);SC-7;SC-7(3);SC-7(5);SC-7(8);SC-7(12);SC-7(13);SC-7(18)
      labels:
        compliance.openshift.io/profile-bundle: ocp4
      name: ocp4-configure-network-policies-namespaces
      namespace: openshift-compliance
    rationale: <description of why this rule is checked>
    severity: high 3
    title: <summary of the rule>

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: rhcos4-with-usb
spec:
  extends: rhcos4-moderate 1
  title: <title of the tailored profile>
  disableRules:
    - name: <name of a rule object to be disabled>
      rationale: <description of why this rule is checked>
status:
  id: xccdf_compliance.openshift.io_profile_rhcos4-with-usb 2
  outputRef:
    name: rhcos4-with-usb-tp 3
    namespace: openshift-compliance
  state: READY 4

apiVersion: compliance.openshift.io/v1alpha1
autoApplyRemediations: true 1
autoUpdateRemediations: true 2
kind: ScanSetting
maxRetryOnTimeout: 3
metadata:
  creationTimestamp: "2022-10-18T20:21:00Z"
  generation: 1
  name: default-auto-apply
  namespace: openshift-compliance
  resourceVersion: "38840"
  uid: 8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/master: ""
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3 3
  size: 1Gi 4
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
roles: 5
- master
- worker
scanTolerations:
- operator: Exists
schedule: 0 1 * * * 6
showNotApplicable: false
strictNodeScan: true
timeout: 30m

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: <name of the scan>
profiles: 1
  # Node checks
  - name: rhcos4-with-usb
    kind: TailoredProfile
    apiGroup: compliance.openshift.io/v1alpha1
  # Cluster checks
  - name: ocp4-moderate
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef: 2
  name: my-companys-constraints
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

$ oc get compliancesuites

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: <name of the scan>
spec:
  autoApplyRemediations: false 1
  schedule: "0 1 * * *" 2
  scans: 3
    - name: workers-scan
      scanType: Node
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
      rule: "xccdf_org.ssgproject.content_rule_no_netrc_files"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
status:
  Phase: DONE 4
  Result: NON-COMPLIANT 5
  scanStatuses:
  - name: workers-scan
    phase: DONE
    result: NON-COMPLIANT

$ oc get events --field-selector involvedObject.kind=ComplianceSuite,involvedObject.name=<name of the suite>

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
  name: <name of the scan>
spec:
  scanType: Node 1
  profile: xccdf_org.ssgproject.content_profile_moderate 2
  content: ssg-ocp4-ds.xml
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc... 3
  rule: "xccdf_org.ssgproject.content_rule_no_netrc_files" 4
  nodeSelector: 5
    node-role.kubernetes.io/worker: ""
status:
  phase: DONE 6
  result: NON-COMPLIANT 7

oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<name of the suite>

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceCheckResult
metadata:
  labels:
    compliance.openshift.io/check-severity: medium
    compliance.openshift.io/check-status: FAIL
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
  name: workers-scan-no-direct-root-logins
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceScan
    name: workers-scan
description: <description of scan check>
instructions: <manual instructions for the scan>
id: xccdf_org.ssgproject.content_rule_no_direct_root_logins
severity: medium 1
status: FAIL 2

oc get compliancecheckresults \
-l compliance.openshift.io/suite=workers-compliancesuite

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  labels:
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
    machineconfiguration.openshift.io/role: worker
  name: workers-scan-disable-users-coredumps
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: workers-scan-disable-users-coredumps
    uid: <UID>
spec:
  apply: false 1
  object:
    current: 2
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       spec:
         config:
           ignition:
             version: 2.2.0
           storage:
             files:
             - contents:
                 source: data:,%2A%20%20%20%20%20hard%20%20%20core%20%20%20%200
               filesystem: root
               mode: 420
               path: /etc/security/limits.d/75-disable_users_coredumps.conf
    outdated: {} 3

oc get complianceremediations \
-l compliance.openshift.io/suite=workers-compliancesuite

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),compliance.openshift.io/automated-remediation'

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),!compliance.openshift.io/automated-remediation'

Compliance Operator를 사용하려면 먼저 클러스터에 배포되었는지 확인해야 합니다.

클러스터 관리자는 OpenShift Container Platform 클러스터에서 Compliance Operator를 업데이트할 수 있습니다.

이 섹션에서는 업데이트된 버전의 규정 준수 콘텐츠를 사용하는 방법과 사용자 정의 ProfileBundle 오브젝트를 만드는 방법을 포함하여 보안 콘텐츠의 라이프사이클에 대해 설명합니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
  creationTimestamp: "2022-10-19T12:06:30Z"
  finalizers:
  - profilebundle.finalizers.compliance.openshift.io
  generation: 1
  name: rhcos4
  namespace: openshift-compliance
  resourceVersion: "46741"
  uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
spec:
  contentFile: ssg-rhcos4-ds.xml 1
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:900e... 2
status:
  conditions:
  - lastTransitionTime: "2022-10-19T12:07:51Z"
    message: Profile bundle successfully parsed
    reason: Valid
    status: "True"
    type: Ready
  dataStreamStatus: VALID

$ oc -n openshift-compliance get profilebundles rhcos4 -oyaml

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
  creationTimestamp: "2022-10-19T12:06:30Z"
  finalizers:
  - profilebundle.finalizers.compliance.openshift.io
  generation: 1
  name: rhcos4
  namespace: openshift-compliance
  resourceVersion: "46741"
  uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
spec:
  contentFile: ssg-rhcos4-ds.xml
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:900e... 1
status:
  conditions:
  - lastTransitionTime: "2022-10-19T12:07:51Z"
    message: Profile bundle successfully parsed
    reason: Valid
    status: "True"
    type: Ready
  dataStreamStatus: VALID

OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 클러스터에서 OpenShift Compliance Operator를 제거할 수 있습니다.

Compliance Operator (CO) 설치의 일부로 사용할 수 있는 여러 프로필이 있습니다. 다음 프로필을 사용하여 클러스터의 격차를 평가할 수는 있지만 사용만으로는 특정 프로필의 준수를 유추하거나 보장하지 않으며 감사자가 아닙니다.

이러한 다양한 표준을 준수하거나 인증하려면 QSA(Qualified Security Assessor), 공동 인증 기관(JAB) 또는 기타 업계가 귀하의 환경을 평가할 수 있는 규제 당국을 고용해야 합니다. 표준을 준수하기 위해 권한 있는 감사자와 협력해야 합니다.

모든 Red Hat 제품의 규정 준수 지원에 대한 자세한 내용은 제품 규정 준수 를 참조하십시오.

Compliance Operator를 사용하여 규정 준수 검사를 실행하도록 ScanSetting 및 ScanSettingBinding API를 사용하는 것이 좋습니다. 이러한 API 오브젝트에 대한 자세한 내용을 보려면 다음을 실행합니다.

$ oc explain scansettings

또는

$ oc explain scansettingbindings

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: default
  namespace: openshift-compliance
rawResultStorage:
  storageClassName: standard
  rotation: 10
  size: 10Gi
roles:
- worker
- master
scanTolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/master
  operator: Exists
schedule: '0 1 * * *'

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-<size>

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests: 1
        memory: "64Mi"
        cpu: "250m"
      limits: 2
        memory: "128Mi"
        cpu: "500m"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]

Compliance Operator는 즉시 사용할 수 있는 프로필과 함께 제공되지만 조직의 필요 및 요구 사항에 맞게 수정해야 합니다. 프로필을 수정하는 프로세스를 조정이라고 합니다.

Compliance Operator는 프로필을 조정하는 데 도움이 되도록 TailoredProfile 오브젝트를 제공합니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: new-profile
  annotations:
    compliance.openshift.io/product-type: Node 1
spec:
  extends: ocp4-cis-node 2
  description: My custom profile 3
  title: Custom profile 4
  enableRules:
    - name: ocp4-etcd-unique-ca
      rationale: We really need to enable this
  disableRules:
    - name: ocp4-file-groupowner-cni-conf
      rationale: This does not apply to the cluster

OpenShift Container Platform 클러스터의 규정 준수를 입증할 때 감사 목적으로 검사 결과를 제공해야 할 수 있습니다.

각 ComplianceCheckResult는 하나의 규정 준수 규칙 검사 결과를 나타냅니다. 규칙을 자동으로 수정할 수 있는 경우 ComplianceCheckResult가 소유한 동일한 이름의 ComplianceRemediation 오브젝트가 생성됩니다. 요청하지 않는 경우 수정은 자동으로 적용되지 않으므로 OpenShift Container Platform 관리자는 수정을 통해 수행되는 작업을 검토하고 확인한 후에만 수정을 적용할 수 있습니다.

$ oc get -n openshift-compliance compliancecheckresults \
  -l compliance.openshift.io/suite=workers-compliancesuite

$ oc get -n openshift-compliance compliancecheckresults \
-l compliance.openshift.io/scan=workers-scan

$ oc get -n openshift-compliance compliancecheckresults \
-l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'

$ oc get compliancecheckresults -n openshift-compliance \
-l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/check-severity=high'

NAME                                                           STATUS   SEVERITY
nist-moderate-modified-master-configure-crypto-policy          FAIL     high
nist-moderate-modified-master-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-master-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-master-enable-fips-mode                 FAIL     high
nist-moderate-modified-master-no-empty-passwords               FAIL     high
nist-moderate-modified-master-selinux-state                    FAIL     high
nist-moderate-modified-worker-configure-crypto-policy          FAIL     high
nist-moderate-modified-worker-coreos-pti-kernel-argument       FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-burstaction   FAIL     high
nist-moderate-modified-worker-disable-ctrlaltdel-reboot        FAIL     high
nist-moderate-modified-worker-enable-fips-mode                 FAIL     high
nist-moderate-modified-worker-no-empty-passwords               FAIL     high
nist-moderate-modified-worker-selinux-state                    FAIL     high
ocp4-moderate-configure-network-policies-namespaces            FAIL     high
ocp4-moderate-fips-mode-enabled-on-all-nodes                   FAIL     high

$ oc get -n openshift-compliance compliancecheckresults \
-l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'

spec:
  apply: false
  current:
  object:
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
              mode: 0644
              contents:
                source: data:,net.ipv4.conf.all.accept_redirects%3D0
  outdated: {}
status:
  applicationState: NotApplied

$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"

net.ipv4.conf.all.accept_redirects=0