보안 및 컴플라이언스

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

컨테이너에서는 물리 서버, 가상 머신(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.8은 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> 버전을 생성합니다.

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 Container Platform 레지스트리를 Red Hat Quay로 교체할 수 있습니다. 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에 대한 모든 네트워크 액세스를 거부하고 수신 컨트롤러의 연결만 허용하거나 다른 프로젝트의 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://<https://username:password@proxy.example.com:123/>
  httpsProxy: https://<https://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 인증서가 포함된 새로운 머신 구성을 적용하면 노드가 재부팅됩니다. 다음 번 부팅 중에 coreos-update-ca-trust.service 서비스는 RHCOS 노드에서 실행되며 새 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 인증서를 사용하는 서비스는 다음과 같습니다.

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

추가 리소스

노드 인증서는 클러스터를 통해 서명합니다. 노드 인증서는 부트스트랩 프로세스를 통해 생성된 인증 기관(CA)에서 제공합니다. 클러스터가 설치되면 노드 인증서가 자동으로 순환됩니다.

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

추가 리소스

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

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

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

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

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

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

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

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

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

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

추가 리소스

OLM(OpenShift 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 서버 인증서를 사용자 정의할 수 없습니다.

Machine Config Operator 인증서는 RHCOS(Red Hat Enterprise Linux CoreOS) 노드와 Machine Config Server 간의 연결을 보호하는 데 사용됩니다.

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

이 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.8 이상에서는 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 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는 다음 규정 준수 프로필을 제공합니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

설치된 Operator의 서브스크립션은 Operator에 대한 업데이트를 추적하고 수신하는 업데이트 채널을 지정합니다. 업데이트 채널을 변경하여 추적을 시작하고 최신 채널에서 업데이트를 받을 수 있습니다.

서브스크립션의 업데이트 채널 이름은 Operator마다 다를 수 있지만 이름 지정 스키마는 일반적으로 지정된 Operator 내의 공통 규칙을 따릅니다. 예를 들어 채널 이름은 Operator(1.2, 1.3) 또는 릴리스 빈도(stable, fast)에서 제공하는 애플리케이션의 마이너 릴리스 업데이트 스트림을 따를 수 있습니다.

Red Hat Customer Portal 랩에는 관리자가 Operator 업데이트를 준비하는 데 도움이 되는 다음 애플리케이션이 포함되어 있습니다.

애플리케이션을 사용하여 Operator Lifecycle Manager 기반 Operator를 검색하고 다양한 버전의 OpenShift Container Platform에서 업데이트 채널당 사용 가능한 Operator 버전을 확인할 수 있습니다. Cluster Version Operator 기반 Operator는 포함되어 있지 않습니다.

OpenShift Container Platform 웹 콘솔을 사용하여 Operator의 업데이트 채널을 변경할 수 있습니다.

설치된 Operator의 서브스크립션에 있는 승인 전략이 수동으로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스될 때 업데이트를 수동으로 승인해야 설치가 시작됩니다.

CIS(Center for Internet Security) 프로필을 사용하여 검사를 실행할 수 있습니다. 편의를 위해 Compliance Operator는 시작 시 적절한 기본값을 사용하여 ScanSetting 오브젝트를 생성합니다. 이 ScanSetting 오브젝트의 이름은 default 입니다.

결과 서버 포드는 원시 자산 보고 형식(ARF)을 저장하는 PV(영구 볼륨)를 마운트합니다. nodeSelector 및 tolerations 특성을 사용하면 결과 서버 포드의 위치를 구성할 수 있습니다.

이는 컨트롤 플레인 노드가 영구 볼륨을 마운트할 수 없는 환경에 유용합니다.

이제 ScanSetting 사용자 정의 리소스를 사용하면 검사 제한 특성을 통해 스캐너 Pod의 기본 CPU 및 메모리 제한을 덮어쓸 수 있습니다. Compliance Operator는 기본값 500Mi 메모리, 스캐너 컨테이너에 100m CPU, api-resource-collector 컨테이너에 100m CPU가 있는 200Mi 메모리를 사용합니다. Operator의 메모리 제한을 설정하려면 OLM 또는 Operator 배포 자체를 통해 설치한 경우 Subscription 오브젝트를 수정합니다.

Compliance Operator의 기본 CPU 및 메모리 제한을 늘리려면 Compliance Operator 리소스 제한 증가를 참조하십시오.

kubelet이 컨테이너를 Pod의 일부로 시작하면 kubelet은 해당 컨테이너의 요청과 메모리 및 CPU에 대한 제한을 컨테이너 런타임으로 전달합니다. Linux에서 컨테이너 런타임은 사용자가 정의한 제한을 적용하고 적용하는 커널 cgroup을 구성합니다.

CPU 제한은 컨테이너에서 사용할 수 있는 CPU 시간을 정의합니다. 각 스케줄링 간격 동안 Linux 커널은 이 제한이 초과되었는지 확인합니다. 이 경우 커널은 cgroup 실행을 재개할 때까지 기다립니다.

contended 시스템에서 여러 개의 다른 컨테이너(cgroups)를 실행하려는 경우 CPU 요청이 큰 워크로드에 작은 요청이 있는 워크로드보다 더 많은 CPU 시간이 할당됩니다. 메모리 요청은 Pod 예약 중에 사용됩니다. cgroup v2를 사용하는 노드에서 컨테이너 런타임은 메모리 요청을 힌트로 사용하여 memory.min 및 memory.low 값을 설정할 수 있습니다.

컨테이너가 이 제한보다 많은 메모리를 할당하려고 하면 Linux 커널 메모리 부족 하위 시스템은 메모리를 할당하려는 컨테이너의 프로세스 중 하나를 중지하여 활성화 및 개입합니다. Pod 또는 컨테이너의 메모리 제한은 emptyDir과 같은 메모리 지원 볼륨의 페이지에도 적용할 수 있습니다.

kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리가 사용되므로 tmpfs emptyDir 볼륨을 추적합니다. 컨테이너가 메모리 요청을 초과하고 실행 중인 노드가 총 메모리가 부족하면 Pod의 컨테이너가 제거될 수 있습니다.

Pod가 생성되면 스케줄러는 Pod를 실행할 노드를 선택합니다. 각 노드에는 Pod에 제공할 수 있는 CPU 및 메모리 양에서 각 리소스 유형에 대한 최대 용량이 있습니다. 스케줄러는 예약된 컨테이너의 리소스 요청 합계가 각 리소스 유형의 용량 노드보다 작은지 확인합니다.

노드의 메모리 또는 CPU 리소스 사용량이 매우 낮지만 용량 검사에서 노드의 리소스 부족으로부터 보호하지 못하는 경우에도 스케줄러에서 노드에 Pod를 배치하지 못할 수 있습니다.

각 컨테이너에서 다음 리소스 제한 및 요청을 지정할 수 있습니다.

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:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests: 1
        memory: "64Mi"
        cpu: "250m"
      limits: 2
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Compliance Operator 설치의 일부로 다양한 프로필을 사용할 수 있습니다. oc get 명령을 사용하여 사용 가능한 프로필, 프로필 세부 정보 및 특정 규칙을 볼 수 있습니다.

ProfileBundle 오브젝트에는 contentImage 가 포함된 컨테이너 이미지의 URL과 규정 준수 콘텐츠가 포함된 파일의 두 가지 정보가 필요합니다. contentFile 매개변수는 파일 시스템의 루트와 상대적입니다. 다음 예와 같이 기본 제공 rhcos4 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

보안 콘텐츠는 ProfileBundle 오브젝트에서 참조하는 컨테이너 이미지로 포함됩니다. ProfileBundles 및 규칙 또는 프로필과 같은 번들에서 구문 분석한 사용자 정의 리소스에 대한 업데이트를 정확하게 추적하려면 태그 대신 다이제스트를 사용하여 규정 준수 콘텐츠가 있는 컨테이너 이미지를 확인하십시오.

$ 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

각 ProfileBundle은 배포를 통해 지원됩니다. Compliance Operator에서 컨테이너 이미지 다이제스트가 변경되었음을 감지하면 배포가 업데이트되어 변경 사항을 반영하고 콘텐츠를 다시 구문 분석합니다. 태그 대신 다이제스트를 사용하면 안정적이고 예측 가능한 프로필 세트를 사용할 수 있습니다.

TailoredProfile 오브젝트를 사용하여 처음부터 맞춤형 프로필을 작성할 수 있습니다. 적절한 제목 과 설명을 설정하고 extends 필드를 비워 둡니다. 이 사용자 정의 프로필이 생성할 Compliance Operator에 검사 유형을 지정합니다.

+ .example new-profile.yaml

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: new-profile
  annotations:
    compliance.openshift.io/product-type: Node 1
spec:
  extends:
  description: My custom profile 2
  title: Custom profile 3

TailoredProfile CR에서는 가장 일반적인 맞춤 작업을 수행할 수 있지만 XCCDF 표준을 사용하면 OpenSCAP 프로필 맞춤 시 유연성이 훨씬 더 향상됩니다. 또한 조직에서 이전에 OpenScap을 사용한 적이 있는 경우 기존 XCCDF 맞춤 파일이 있을 수 있으며 이 파일을 다시 사용할 수 있습니다.

ComplianceSuite 오브젝트에는 사용자 정의 맞춤 파일을 가리킬 수 있는 선택적 TailoringConfigMap 특성이 포함되어 있습니다. TailoringConfigMap 특성 값은 구성 맵의 이름으로, 이 맵에는 tailoring.xml이라는 키가 포함되어야 하며 이 키의 값은 맞춤 콘텐츠입니다.

기본적으로 ComplianceCheckResult 오브젝트에는 검사를 쿼리하고 결과가 생성된 후 다음 단계를 결정할 수 있는 몇 가지 유용한 레이블이 지정됩니다.

특정 제품군에 속하는 검사를 나열합니다.

$ 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

일부 ComplianceCheckResult 오브젝트가 ComplianceRemediation 오브젝트를 생성하는 것은 아닙니다. 자동으로 업데이트를 적용할 수 있는 ComplianceCheckResult 오브젝트만 해당합니다. ComplianceCheckResult 오브젝트에 compliance.openshift.io/automated-remediation 레이블이 지정된 경우 관련된 업데이트 적용이 있습니다. 업데이트 적용의 이름은 검사 이름과 동일합니다.

자동으로 업데이트를 적용할 수 있는 모든 실패한 검사를 나열합니다.

$ 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'

수동 업데이트 적용 단계는 일반적으로 ComplianceCheckResult 오브젝트의 description 속성에 저장됩니다.

수정이 포함된 ComplianceRemediation 오브젝트 및 ComplianceCheckResult 오브젝트를 모두 검토합니다. ComplianceCheckResult 오브젝트에는 검사에서 수행하는 작업과 방지를 위한 강화 작업에 관해 사람이 있을 수 있는 설명과 심각도 및 관련 보안 제어와 같은 기타 메타데이터가 포함되어 있습니다. ComplianceRemediation 오브젝트는 ComplianceCheckResult에서 설명하는 문제를 해결하는 방법을 나타냅니다. 첫 번째 검사 후 상태가 누락된 상태로 수정되는지 확인합니다.

다음은 sysctl-net-ipv4-conf-all-accept-redirects라는 검사와 수정의 예입니다. 이 예는 spec 및 status만 표시하고 metadata는 생략하도록 수정되었습니다.

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

수정 페이로드는 spec.current 특성에 저장됩니다. 페이로드는 임의의 Kubernetes 오브젝트일 수 있지만 이 수정은 노드 검사를 통해 생성되었기 때문에 위 예의 수정 페이로드는 MachineConfig 오브젝트입니다. 플랫폼 검사의 경우 수정 페이로드는 종종 다른 종류의 오브젝트(예: ConfigMap 또는 Secret 오브젝트)에 해당하지만 일반적으로 이러한 수정을 적용하는 것은 관리자의 몫입니다. 그러지 않으면 일반 Kubernetes 오브젝트를 조작하기 위해 Compliance Operator에 매우 광범위한 권한이 있어야 하기 때문입니다. 플랫폼 검사를 수정하는 예는 본문 뒷부분에 있습니다.

수정 적용 시 수행되는 작업을 정확히 확인하기 위해 MachineConfig 오브젝트 콘텐츠에서는 구성에 Ignition 오브젝트를 사용합니다. 형식에 대한 자세한 내용은 Ignition 사양을 참조하십시오. 이 예에서 spec.config.storage.files[0].path 특성은 이 수정(/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf)으로 생성되는 파일을 지정하고, spec.config.storage.files[0].contents.source 특성은 해당 파일의 콘텐츠를 지정합니다.

콘텐츠를 보려면 다음 Python 스크립트를 사용합니다.

$ 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

사용자 지정 MachineConfigPool 을 생성할 때 KubeletConfig 에 있는 machineConfigPoolSelector 가 MachineConfigPool과 일치하는 라벨과 일치하도록 MachineConfigPool 에 레이블을 추가합니다.

OpenShift Container Platform 인프라에는 런타임에 불완전한 구성 파일이 포함될 수 있으며 노드는 누락된 구성 옵션의 기본 구성 값을 가정합니다. 일부 설정 옵션은 명령줄 인수로 전달할 수 있습니다. 결과적으로 Compliance Operator는 규칙 검사에 사용된 옵션이 누락될 수 있으므로 노드의 구성 파일이 완료되었는지 확인할 수 없습니다.

기본 구성 값이 검사를 통과하는 잘못된 음수 결과를 방지하기 위해 Compliance Operator는 Node/Proxy API를 사용하여 노드 풀의 노드 간에 일관된 모든 구성 옵션이 해당 노드 풀 내의 모든 노드에 대한 구성을 나타내는 파일에 저장됩니다. 이렇게 하면 검사 결과의 정확성이 높아집니다.

기본 마스터 및 작업자 노드 풀 구성에서 이 기능을 사용하려면 추가 구성을 변경할 필요가 없습니다.

Compliance Operator는 각 노드 풀 구성의 사본을 유지하지 않습니다. Compliance Operator는 단일 노드 풀 내의 모든 노드에 대한 일관된 구성 옵션을 구성 파일의 사본으로 집계합니다. 그런 다음 Compliance Operator는 특정 노드 풀에 구성 파일을 사용하여 해당 풀 내의 노드에 대한 규칙을 평가합니다.

클러스터에서 기본 작업자 및 마스터 노드 풀 외부에서 사용자 정의 노드 풀을 사용하는 경우 Compliance Operator에서 해당 노드 풀에 대한 구성 파일을 집계하도록 추가 변수를 제공해야 합니다.

Compliance Operator는 Node/Proxy API 오브젝트를 통해 런타임 KubeletConfig 를 확인한 다음 ocp-var-role-master 및 ocp-var-role-worker 와 같은 변수를 사용하여 검사를 수행하는 노드를 결정합니다. ComplianceCheckResult 에서 KubeletConfig 규칙은 ocp4-cis-kubelet-* 로 표시됩니다. 선택한 모든 노드가 이 검사를 통과한 경우에만 검사가 전달됩니다.

KubeletConfig 수정 라벨은 MachineConfigPool 하위 풀에 적용할 수 있습니다.

부울 특성 spec.apply는 Compliance Operator에서 수정을 적용해야 하는지를 제어합니다. 특성을 true로 설정하면 수정을 적용할 수 있습니다.

$ oc -n openshift-compliance \
patch complianceremediations/<scan-name>-sysctl-net-ipv4-conf-all-accept-redirects \
--patch '{"spec":{"apply":true}}' --type=merge

Compliance Operator에서 적용된 수정을 처리하면 status.ApplicationState 특성이 Applied로 변경되거나 잘못된 경우 Error로 변경됩니다. 시스템 구성 수정이 적용되면 적용된 기타 모든 수정과 함께 해당 수정이 75-$scan-name-$suite-name이라는 MachineConfig 오브젝트로 렌더링됩니다. 이후 Machine Config Operator에서 MachineConfig 오브젝트를 렌더링하고 마지막으로 각 노드에서 실행되는 머신 제어 데몬 인스턴스에서 머신 구성 풀의 모든 노드에 이 오브젝트를 적용합니다.

Machine Config Operator에서 새 MachineConfig 오브젝트를 풀의 노드에 적용하면 풀에 속하는 모든 노드가 재부팅됩니다. 이러한 방법은 복합적인 75-$scan-name-$suite-name MachineConfig 오브젝트를 각각 다시 렌더링하는 수정을 여러 번 적용할 때 불편할 수 있습니다. 수정을 즉시 적용하지 않으려면 MachineConfigPool 오브젝트의 .spec.paused 특성을 true로 설정하여 머신 구성 풀을 일시 중지하면 됩니다.

Compliance Operator는 수정을 자동으로 적용할 수 있습니다. ScanSetting 최상위 오브젝트에 autoApplyRemediations: true를 설정합니다.

플랫폼 검사에 대한 점검은 일반적으로 다음 두 가지 이유로 관리자가 수동으로 수정해야 합니다.

새 버전의 규정 준수 콘텐츠를 사용하는 경우 이전 버전과 다른 새 버전의 수정을 제공할 수 있습니다. Compliance Operator는 이전 버전의 수정을 적용한 상태로 유지됩니다. OpenShift Container Platform 관리자에게는 검토하고 적용할 새 버전에 대한 알림이 제공됩니다. 이전에 적용되었지만 업데이트된 ComplianceRemediation 오브젝트는 상태가 Outdated로 변경됩니다. 오래된 오브젝트는 쉽게 검색할 수 있도록 레이블이 지정됩니다.

이전에 적용된 수정 내용은 ComplianceRemediation 오브젝트의 spec.outdated 특성에 저장되고 새로 업데이트된 내용은 spec.current 특성에 저장됩니다. 콘텐츠가 최신 버전으로 업데이트되면 관리자는 수정을 검토해야 합니다. spec.outdated 특성이 존재하는 동안에는 결과 MachineConfig 오브젝트를 렌더링하는 데 사용됩니다. spec.outdated 특성이 제거되면 Compliance Operator에서 결과 MachineConfig 오브젝트를 다시 렌더링하고 이로 인해 Operator에서 구성을 노드로 푸시합니다.

이전에 적용한 수정을 적용 취소해야 할 수 있습니다.

KubeletConfig 수정은 노드 수준 프로필에 포함됩니다. KubeletConfig 수정을 제거하려면 KubeletConfig 오브젝트에서 수동으로 제거해야 합니다. 이 예에서는 one-rule-tp-node-master-kubelet-eviction-thresholds-hard-imagefs-available 수정에 대한 규정 준수 검사를 제거하는 방법을 보여줍니다.

ScanSetting 오브젝트는 ScanSetting 또는 ScanSettingBinding 오브젝트에서 생성한 규정 준수 검사에서 검사할 노드 역할을 나열합니다. 각 노드 역할은 일반적으로 머신 구성 풀에 매핑됩니다.

일부 결과가 다른 결과와 다른 경우 Compliance Operator는 일부 노드에서 INCONSISTENT로 보고하는 ComplianceCheckResult 오브젝트에 플래그를 지정합니다. 또한 모든 ComplianceCheckResult 오브젝트에는 compliance.openshift.io/inconsistent-check 레이블이 지정됩니다.

풀의 머신 수가 상당히 많을 수 있기 때문에 Compliance Operator는 가장 일반적인 상태를 찾고 일반적인 상태와 다른 노드를 나열하려고 합니다. 가장 일반적인 상태는 compliance.openshift.io/most-common-status 주석에 저장되고 주석 compliance.openshift.io/inconsistent-source에는 가장 일반적인 상태와 다른 점검 상태의 hostname:status 쌍이 포함됩니다. 일반적인 상태를 찾을 수 없는 경우 모든 hostname:status 쌍이 compliance.openshift.io/inconsistent-source annotation에 나열됩니다.

가능한 경우 클러스터가 규정 준수 상태에 통합될 수 있도록 수정이 계속 생성됩니다. 그러나 이러한 통합이 항상 가능한 것은 아니며 노드 간 차이를 수동으로 수정해야 합니다. compliance.openshift.io/rescan= 옵션으로 검사에 주석을 달아 일관된 결과를 가져오도록 규정 준수 검사를 다시 실행해야 합니다.

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

사용자가 ScanSetting 및 ScanSettingBinding 오브젝트를 활용하여 모음과 검사를 정의하는 것이 바람직하지만 ComplianceSuite 오브젝트를 직접 정의하는 유효한 사용 사례가 있습니다.

다음 예제에서는 단일 규칙으로만 작업자 머신을 검사하는 ComplianceSuite를 보여줍니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: workers-compliancesuite
spec:
  scans:
    - name: workers-scan
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: quay.io/complianceascode/ocp4:latest
      debug: true
      rule: xccdf_org.ssgproject.content_rule_no_direct_root_logins
      nodeSelector:
      node-role.kubernetes.io/worker: ""

위에서 언급한 ComplianceSuite 오브젝트 및 ComplianceScan 오브젝트는 여러 특성을 OpenSCAP에서 예상하는 형식으로 지정합니다.

프로필, 콘텐츠 또는 규칙 값을 찾으려면 ScanSetting 및 ScanSettingBinding에서 유사한 모음을 생성하여 시작하거나 규칙 또는 프로필과 같이 ProfileBundle 오브젝트에서 구문 분석한 오브젝트를 검사하면 됩니다. 이러한 오브젝트에는 ComplianceSuite에서 참조하는 데 사용할 수 있는 xccdf_org 식별자가 포함되어 있습니다.

대규모 환경에서는 기본 PriorityClass 오브젝트가 너무 작아 Pod가 제 시간에 검사를 실행할 수 있도록 할 수 있습니다. 규정 준수를 유지하거나 자동화된 스캔을 보장해야 하는 클러스터의 경우 PriorityClass 변수를 설정하여 리소스 제약 상황에서 Compliance Operator가 항상 우선순위가 지정되도록 하는 것이 좋습니다.

TailoredProfile CR에서는 가장 일반적인 맞춤 작업을 수행할 수 있지만 XCCDF 표준을 사용하면 OpenSCAP 프로필 맞춤 시 유연성이 훨씬 더 향상됩니다. 또한 조직에서 이전에 OpenScap을 사용한 적이 있는 경우 기존 XCCDF 맞춤 파일이 있을 수 있으며 이 파일을 다시 사용할 수 있습니다.

ComplianceSuite 오브젝트에는 사용자 정의 맞춤 파일을 가리킬 수 있는 선택적 TailoringConfigMap 특성이 포함되어 있습니다. TailoringConfigMap 특성 값은 구성 맵의 이름으로, 이 맵에는 tailoring.xml이라는 키가 포함되어야 하며 이 키의 값은 맞춤 콘텐츠입니다.

일반적으로 매주 월요일 또는 매일 등 정의된 일정에 따라 검사를 다시 실행하려고 할 것입니다. 노드 문제를 해결한 후 다시 한 번 검사를 실행하는 것도 유용할 수 있습니다. 단일 검사를 수행하려면 compliance.openshift.io/rescan= 옵션을 사용하여 검사에 주석을 답니다.

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

재검사는 rhcos-moderate 프로파일에 대해 4개의 추가 mc 를 생성합니다.

$ oc get mc

75-worker-scan-chronyd-or-ntpd-specify-remote-server
75-worker-scan-configure-usbguard-auditbackend
75-worker-scan-service-usbguard-enabled
75-worker-scan-usbguard-allow-hid-and-hub

ComplianceCheckResult와 같은 사용자 정의 리소스는 검사한 모든 노드에서 집계한 한 번의 점검 결과를 나타내지만 스캐너에서 생성한 원시 결과를 검토하는 것이 유용할 수 있습니다. 원시 결과는 ARF 형식으로 생성되며 크기가 클 수 있습니다(노드당 수십 메가바이트). 따라서 etcd 키-값 저장소에서 지원하는 Kubernetes 리소스에 저장하는 것은 비현실적입니다. 대신 검사할 때마다 기본 크기가 1GB인 영구 볼륨(PV)이 생성됩니다. 환경에 따라 적절하게 PV 크기를 늘릴 수 있습니다. 크기를 늘리려면 ScanSetting 및 ComplianceScan 리소스 모두에 노출되는 rawResultStorage.size 특성을 사용하면 됩니다.

관련 매개변수는 rawResultStorage.rotation으로, 이전 검사가 되풀이되기 전에 PV에 유지되는 검사 수를 조절합니다. 기본값은 3이며 되풀이 정책을 0으로 설정하면 되풀이가 비활성화됩니다. 기본 되풀이 정책과 원시 ARF 검사 보고서당 100MB의 추정치가 지정되면 환경에 적합한 PV 크기를 계산할 수 있습니다.

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 * * *'

ComplianceSuite 오브젝트에서 autoApplyRemediations 부울 매개 변수를 사용할 수 있지만, 대신 compliance.openshift.io/apply-remediations로 오브젝트에 주석을 달 수 있습니다. 이를 통해 Operator는 생성된 모든 수정 사항을 적용할 수 있습니다.

$ oc -n openshift-compliance \
annotate compliancesuites/workers-compliancesuite compliance.openshift.io/apply-remediations=

경우에 따라 최신 콘텐츠가 있는 검사에서 OUTDATED로 업데이트 적용을 표시할 수 있습니다. 관리자는 compliance.openshift.io/remove-outdated 주석을 적용하여 새 업데이트를 적용하고 오래된 항목을 제거할 수 있습니다.

$ oc -n openshift-compliance \
annotate compliancesuites/workers-compliancesuite compliance.openshift.io/remove-outdated=

또는 ScanSetting 또는 ComplianceSuite 오브젝트에 autoUpdateRemediations 플래그를 설정하여 수정 사항을 자동으로 업데이트합니다.

일부 환경에서는 Compliance Operator api-resource-collector 에서 올바른 권한을 사용할 수 있도록 사용자 정의 SCC(보안 컨텍스트 제약 조건) 파일을 생성해야 합니다.

다음 섹션에서는 Compliance Operator 검사의 구성 요소 및 단계를 간략하게 설명합니다.

$ oc get -n openshift-compliance profilebundle.compliance

$ oc get -n openshift-compliance profile.compliance

$ oc logs -n openshift-compliance -lprofile-bundle=ocp4 -c profileparser

$ oc get -n openshift-compliance deployments,pods -lprofile-bundle=ocp4

$ oc logs -n openshift-compliance pods/<pod-name>

$ oc describe -n openshift-compliance pod/<pod-name> -c profileparser

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: my-companys-constraints
debug: true
# For each role, a separate scan will be created pointing
# to a node-role specified in roles
roles:
  - worker
---
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: my-companys-compliance-requirements
profiles:
  # Node checks
  - name: rhcos4-e8
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
  # Cluster checks
  - name: ocp4-e8
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: my-companys-constraints
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

Events:
  Type     Reason        Age    From                    Message
  ----     ------        ----   ----                    -------
  Normal   SuiteCreated  9m52s  scansettingbindingctrl  ComplianceSuite openshift-compliance/my-companys-compliance-requirements created

$ oc get cronjobs

NAME                                           SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
<cron_name>                                    0 1 * * *   False     0        <none>          151m

$ oc -n openshift-compliance get cm \
-l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=

$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker

$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels

NAME                                                              READY   STATUS      RESTARTS   AGE   LABELS
rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod   0/2     Completed   0          39m   compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner

$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker

NAME                                                       STATUS   SEVERITY
rhcos4-e8-worker-accounts-no-uid-except-zero               PASS     high
rhcos4-e8-worker-audit-rules-dac-modification-chmod        FAIL     medium

$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker

NAME                                                       STATE
rhcos4-e8-worker-audit-rules-dac-modification-chmod        NotApplied
rhcos4-e8-worker-audit-rules-dac-modification-chown        NotApplied
rhcos4-e8-worker-audit-rules-execution-chcon               NotApplied
rhcos4-e8-worker-audit-rules-execution-restorecon          NotApplied
rhcos4-e8-worker-audit-rules-execution-semanage            NotApplied
rhcos4-e8-worker-audit-rules-execution-setfiles            NotApplied

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge

$ oc get mc | grep 75-

75-rhcos4-e8-worker-my-companys-compliance-requirements                                                3.2.0             2m46s

$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements

Name:         75-rhcos4-e8-worker-my-companys-compliance-requirements
Labels:       machineconfiguration.openshift.io/role=worker
Annotations:  remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:

$ oc -n openshift-compliance \
annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=

$ oc -n openshift-compliance \
get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod

NAME                                                  STATUS   SEVERITY
rhcos4-e8-worker-audit-rules-dac-modification-chmod   PASS     medium

$ oc logs -l workload=<workload_name> -c <container_name>

경우에 따라 Compliance Operator에 기본 제한 허용보다 많은 메모리가 필요할 수 있습니다. 이 문제를 완화하는 가장 좋은 방법은 사용자 정의 리소스 제한을 설정하는 것입니다.

스캐너 Pod의 기본 메모리 및 CPU 제한을 늘리려면 'ScanSetting' 사용자 정의 리소스를 참조하십시오.

resources 필드는 OLM(Operator Lifecycle Manager)에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.

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

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

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

Compliance Operator를 제거하려면 먼저 Compliance Operator CRD(사용자 정의 리소스 정의)를 삭제해야 합니다. CRD가 제거되면 openshift-compliance 프로젝트를 삭제하여 Operator 및 해당 네임스페이스를 제거할 수 있습니다.

규정 준수 검사가 완료되면 결과 ComplianceCheckResult CR(사용자 정의 리소스)에 개별 검사 결과가 나열됩니다. 그러나 관리자 또는 감사자는 검사에 대한 전체 세부 정보가 필요할 수 있습니다. OpenSCAP 툴은 자세한 결과를 사용하여 AMQP(Advanced Recording Format) 포맷 파일을 생성합니다. 이 ARF 파일은 구성 맵 또는 기타 표준 Kubernetes 리소스에 저장하기에 너무 크므로 이를 포함할 영구 볼륨(PV)이 생성됩니다.

디렉터리에서 파일 목록을 확인합니다.

$ ls /tmp/ocp4-cis-node-master/

ocp4-cis-node-master-ip-10-0-128-89.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-150-5.ec2.internal-pod.xml.bzip2  ocp4-cis-node-master-ip-10-0-163-32.ec2.internal-pod.xml.bzip2

결과를 추출합니다.

$ bunzip2 -c resultsdir/worker-scan/worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 > resultsdir/worker-scan/worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml

결과를 확인합니다.

$ ls resultsdir/worker-scan/

worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml
worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2
worker-scan-stage-459-tqkg7-compute-1-pod.xml.bzip2

예약된 작업으로 스캔을 실행할 수 있지만 수정을 적용한 후 또는 클러스터에 대한 기타 변경이 이루어진 경우 필요에 따라 검사를 다시 실행해야 합니다.

Compliance Operator에서 제공하는 ScanSetting 및 ScanSettingBinding CR(사용자 정의 리소스)을 사용하는 경우 schedule, machine roles, tolerations 등과 같은 공통 검사 옵션 세트를 사용하는 동안 여러 프로필 검사를 실행할 수 있습니다. 여러 ComplianceSuite 또는 ComplianceScan 오브젝트로 작업하는 것보다 쉽지만 새로운 사용자를 혼란스럽게 할 수 있습니다.

oc compliance bind 하위 명령은 ScanSettingBinding CR을 생성하는 데 도움이 됩니다.

컴플라이언스 표준은 일반적으로 다음과 같이 계층 구조로 구성됩니다.

Compliance Operator는 클러스터를 준수하는 데 필요한 변경 사항을 자동화하는 데 사용되는 수정 오브젝트를 제공합니다. fetch-fixes 하위 명령은 어떤 구성 수정이 사용되는지 정확하게 이해하는 데 도움이 될 수 있습니다. fetch-fixes 하위 명령을 사용하여 프로필, 규칙 또는 ComplianceRemediation 오브젝트에서 검사할 디렉터리로 수정 오브젝트를 추출합니다.

검사 실행이 완료되면 개별 검사 규칙에 대해 ComplianceCheckResult 오브젝트가 생성됩니다. view-result 하위 명령은 사용자가 읽을 수 있는 ComplianceCheckResult 오브젝트 세부 정보 출력을 제공합니다.

CRD는 다음 워크플로우를 제공하여 규정 준수 검사를 완료합니다.

기본적으로 Compliance Operator CRD에는 ProfileBundle 및 Profile 오브젝트가 포함되며 규정 준수 검사 요구 사항에 대한 규칙을 정의하고 설정할 수 있습니다. TailoredProfile 오브젝트를 사용하여 기본 프로필을 사용자 지정할 수도 있습니다.

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

컴플라이언스 검사의 요구 사항을 정의한 후에는 검사 유형, 검사 발생 및 검사 위치를 지정하여 구성할 수 있습니다. 이를 위해 Compliance Operator는 ScanSetting 오브젝트를 제공합니다.

Name:                      default-auto-apply
Namespace:                 openshift-compliance
Labels:                    <none>
Annotations:               <none>
API Version:               compliance.openshift.io/v1alpha1
Auto Apply Remediations:   true
Auto Update Remediations:  true
Kind:                      ScanSetting
Metadata:
  Creation Timestamp:  2022-10-18T20:21:00Z
  Generation:          1
  Managed Fields:
    API Version:  compliance.openshift.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:autoApplyRemediations: 1
      f:autoUpdateRemediations: 2
      f:rawResultStorage:
        .:
        f:nodeSelector:
          .:
          f:node-role.kubernetes.io/master:
        f:pvAccessModes:
        f:rotation:
        f:size:
        f:tolerations:
      f:roles:
      f:scanTolerations:
      f:schedule:
      f:showNotApplicable:
      f:strictNodeScan:
    Manager:         compliance-operator
    Operation:       Update
    Time:            2022-10-18T20:21:00Z
  Resource Version:  38840
  UID:               8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
Raw Result Storage:
  Node Selector:
    node-role.kubernetes.io/master:
  Pv Access Modes:
    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
    Toleration Seconds:  300
    Effect:              NoExecute
    Key:                 node.kubernetes.io/unreachable
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoSchedule
    Key:                 node.kubernetes.io/memory-pressure
    Operator:            Exists
Roles: 5
  master
  worker
Scan Tolerations:
  Operator:           Exists
Schedule:             "0 1 * * *" 6
Show Not Applicable:  false
Strict Node Scan:     true
Events:               <none>

규정 준수 검사 요구 사항을 정의하고 검사를 실행하도록 설정을 구성한 경우 Compliance Operator는 ScanSettingBinding 오브젝트를 사용하여 처리합니다.

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

규정 준수 제품군 생성 후 ComplianceSuite 오브젝트를 사용하여 배포된 검사의 상태를 모니터링할 수 있습니다.

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: quay.io/complianceascode/ocp4:latest
      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: quay.io/complianceascode/ocp4:latest 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>

규정 준수 제품군이 DONE 단계에 도달하면 검사 결과 및 가능한 수정을 확인할 수 있습니다.

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'

OpenShift File Integrity Operator 1.0.0에서 다음 권고를 사용할 수 있습니다.

File Integrity Operator가 안정적이며 릴리스 채널이 v1 로 업그레이드되었습니다. 향후 릴리스에서는 Semantic Versioning 을 따릅니다. 최신 릴리스에 액세스하려면 File Integrity Operator 업데이트를 참조하십시오.

OpenShift File Integrity Operator 0.1.32에서는 다음 권고를 사용할 수 있습니다.

OpenShift File Integrity Operator 0.1.30에서 다음 권고를 사용할 수 있습니다.

OpenShift File Integrity Operator 0.1.24에 다음 권고를 사용할 수 있습니다.

다음 권고는 OpenShift File Integrity Operator 0.1.22에 제공됩니다.

다음 권고는 OpenShift File Integrity Operator 0.1.21에 사용할 수 있습니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

설치된 Operator의 서브스크립션은 Operator에 대한 업데이트를 추적하고 수신하는 업데이트 채널을 지정합니다. 업데이트 채널을 변경하여 추적을 시작하고 최신 채널에서 업데이트를 받을 수 있습니다.

서브스크립션의 업데이트 채널 이름은 Operator마다 다를 수 있지만 이름 지정 스키마는 일반적으로 지정된 Operator 내의 공통 규칙을 따릅니다. 예를 들어 채널 이름은 Operator(1.2, 1.3) 또는 릴리스 빈도(stable, fast)에서 제공하는 애플리케이션의 마이너 릴리스 업데이트 스트림을 따를 수 있습니다.

Red Hat Customer Portal 랩에는 관리자가 Operator 업데이트를 준비하는 데 도움이 되는 다음 애플리케이션이 포함되어 있습니다.

애플리케이션을 사용하여 Operator Lifecycle Manager 기반 Operator를 검색하고 다양한 버전의 OpenShift Container Platform에서 업데이트 채널당 사용 가능한 Operator 버전을 확인할 수 있습니다. Cluster Version Operator 기반 Operator는 포함되어 있지 않습니다.

OpenShift Container Platform 웹 콘솔을 사용하여 Operator의 업데이트 채널을 변경할 수 있습니다.

설치된 Operator의 서브스크립션에 있는 승인 전략이 수동으로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스될 때 업데이트를 수동으로 승인해야 설치가 시작됩니다.

FileIntegrity 사용자 정의 리소스(CR) 인스턴스는 하나 이상의 노드에 대한 연속적인 파일 무결성 검사 세트를 나타냅니다.

각 FileIntegrity CR은 FileIntegrity CR 사양과 일치하는 노드에서 AIDE를 실행하는 데몬 세트에서 지원합니다.

FileIntegrity 사용자 정의 리소스(CR)는 .status.phase 하위 리소스를 통해 해당 상태를 보고합니다.

FileIntegrity CR의 검사 결과는 FileIntegrityNodeStatuses라는 다른 오브젝트에 보고됩니다.

$ oc get fileintegritynodestatuses

NAME                                                AGE
worker-fileintegrity-ip-10-0-130-192.ec2.internal   101s
worker-fileintegrity-ip-10-0-147-133.ec2.internal   109s
worker-fileintegrity-ip-10-0-165-160.ec2.internal   102s

노드당 하나의 결과 오브젝트가 있습니다. 각 FileIntegrityNodeStatus 오브젝트의 nodeName 특성은 검사 중인 노드에 해당합니다. 파일 무결성 검사의 상태는 results 배열에 표시되며 여기에는 검사 조건이 포함됩니다.

$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq

fileintegritynodestatus 오브젝트는 AIDE 실행의 최신 상태를 보고하고 status 필드에 Failed, Succeeded, Errored로 표시합니다.

$ oc get fileintegritynodestatuses -w

NAME                                                               NODE                                         STATUS
example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal   ip-10-0-134-186.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal   ip-10-0-150-230.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-169-137.us-east-2.compute.internal   ip-10-0-169-137.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal   ip-10-0-180-200.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal    ip-10-0-194-66.us-east-2.compute.internal    Failed
example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal   ip-10-0-222-188.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal   ip-10-0-134-186.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal   ip-10-0-222-188.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal    ip-10-0-194-66.us-east-2.compute.internal    Failed
example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal   ip-10-0-150-230.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal   ip-10-0-180-200.us-east-2.compute.internal   Succeeded

이러한 조건은 해당 FileIntegrityNodeStatus CR 상태의 결과 배열에 보고됩니다.

[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:45:57Z"
  }
]
[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:46:03Z"
  }
]
[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:45:48Z"
  }
]

$ oc debug node/ip-10-0-130-192.ec2.internal

Creating debug namespace/openshift-debug-node-ldfbj ...
Starting pod/ip-10-0-130-192ec2internal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.130.192
If you don't see a command prompt, try pressing enter.
sh-4.2# echo "# integrity test" >> /host/etc/resolv.conf
sh-4.2# exit

Removing debug pod ...
Removing debug namespace/openshift-debug-node-ldfbj ...

$ oc get fileintegritynodestatuses.fileintegrity.openshift.io/worker-fileintegrity-ip-10-0-130-192.ec2.internal -ojsonpath='{.results}' | jq -r

$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq

[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:54:14Z"
  },
  {
    "condition": "Failed",
    "filesChanged": 1,
    "lastProbeTime": "2020-09-15T12:57:20Z",
    "resultConfigMapName": "aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed",
    "resultConfigMapNamespace": "openshift-file-integrity"
  }
]

$ oc describe cm aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed

Name:         aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed
Namespace:    openshift-file-integrity
Labels:       file-integrity.openshift.io/node=ip-10-0-130-192.ec2.internal
              file-integrity.openshift.io/owner=worker-fileintegrity
              file-integrity.openshift.io/result-log=
Annotations:  file-integrity.openshift.io/files-added: 0
              file-integrity.openshift.io/files-changed: 1
              file-integrity.openshift.io/files-removed: 0

Data

integritylog:
------
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2020-09-15 12:58:15

Summary:
  Total number of files:  31553
  Added files:                0
  Removed files:            0
  Changed files:            1


---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /hostroot/etc/resolv.conf

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------


File: /hostroot/etc/resolv.conf
 SHA512   : sTQYpB/AL7FeoGtu/1g7opv6C+KT1CBJ , qAeM+a8yTgHPnIHMaRlS+so61EN8VOpg

Events:  <none>

FileIntegrity 및 FileIntegrityNodeStatus 오브젝트의 상태의 전환은 이벤트에서 기록됩니다. 이벤트 생성 시간은 Active로 Initializing과 같은 최신 전환을 반영하며 반드시 최신 검사 결과가 반영되는 것은 아닙니다. 그러나 최신 이벤트는 항상 최근 상태를 반영합니다.

$ oc get events --field-selector reason=FileIntegrityStatus

LAST SEEN   TYPE     REASON                OBJECT                                MESSAGE
97s         Normal   FileIntegrityStatus   fileintegrity/example-fileintegrity   Pending
67s         Normal   FileIntegrityStatus   fileintegrity/example-fileintegrity   Initializing
37s         Normal   FileIntegrityStatus   fileintegrity/example-fileintegrity   Active

노드 검사에 실패하면 add/changed/removed 및 config map 정보를 사용하여 이벤트가 생성됩니다.

$ oc get events --field-selector reason=NodeIntegrityStatus

LAST SEEN   TYPE      REASON                OBJECT                                MESSAGE
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-134-173.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-168-238.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-169-175.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-152-92.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-158-144.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-131-30.ec2.internal
87m         Warning   NodeIntegrityStatus   fileintegrity/example-fileintegrity   node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed

추가, 변경 또는 제거된 파일의 수를 변경하면 노드 상태가 전환되지 않은 경우에도 새 이벤트가 생성됩니다.

$ oc get events --field-selector reason=NodeIntegrityStatus

LAST SEEN   TYPE      REASON                OBJECT                                MESSAGE
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-134-173.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-168-238.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-169-175.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-152-92.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-158-144.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-131-30.ec2.internal
87m         Warning   NodeIntegrityStatus   fileintegrity/example-fileintegrity   node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed
40m         Warning   NodeIntegrityStatus   fileintegrity/example-fileintegrity   node ip-10-0-152-92.ec2.internal has changed! a:3,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed

모든 Kubernetes 사용자 정의 리소스(CR)와 마찬가지로 oc explain fileintegrity를 실행하면 다음을 사용하여 개별 특성을 볼 수 있습니다.

$ oc explain fileintegrity.spec

$ oc explain fileintegrity.spec.config

기본 File Integrity Operator 구성은 FileIntegrity CR과 동일한 이름으로 구성 맵에 저장됩니다.

다음은 구성 맵의 aide.conf 키에서 발췌한 것입니다.

@@define DBDIR /hostroot/etc/kubernetes
@@define LOGDIR /hostroot/etc/kubernetes
database=file:@@{DBDIR}/aide.db.gz
database_out=file:@@{DBDIR}/aide.db.gz
gzip_dbout=yes
verbose=5
report_url=file:@@{LOGDIR}/aide.log
report_url=stdout
PERMS = p+u+g+acl+selinux+xattrs
CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs

/hostroot/boot/    	CONTENT_EX
/hostroot/root/\..* PERMS
/hostroot/root/   CONTENT_EX

FileIntegrity 인스턴스의 기본 구성은 다음 디렉터리의 파일에 대한 적용 범위를 제공합니다.

다음 디렉터리에는 적용되지 않습니다.

DBDIR, LOGDIR, database, database_out과 같은 AIDE 내부 동작을 구성하는 모든 항목을 Operator에서 덮어씁니다. Operator는 무결성 변경을 확인할 모든 경로 앞에 /hostroot/ 접두사를 추가합니다. 그러면 대부분 컨테이너화된 환경에 맞게 조정되지 않고 루트 디렉터리에서 더 쉽게 시작할 수 있는 기존 AIDE 구성이 재사용됩니다.

이 예제에서는 worker-fileintegrity CR에 제공된 기본 구성을 기반으로 컨트롤 플레인 노드 (마스터 노드라고도 함)에서 실행되는 스캐너의 사용자 정의 구성을 정의하는 데 중점을 둡니다. 이 워크플로는 데몬 세트로 실행되는 사용자 정의 소프트웨어를 배포하고 컨트롤 플레인 노드의 /opt/mydaemon에 데이터를 저장하려는 경우 유용할 수 있습니다.

파일 무결성 구성을 변경하려면 생성된 구성 맵을 변경하지 마십시오. 대신 spec.name, namespace, key 특성을 통해 FileIntegrity 오브젝트에 연결된 구성 맵을 변경하십시오.

File Integrity Operator에서 계획된 변경을 감지하면 데이터베이스를 다시 초기화해야 할 수 있습니다.

OpenShift Container Platform 4에서 클러스터 노드 구성은 MachineConfig 오브젝트를 통해 제공됩니다. MachineConfig 오브젝트로 인해 파일 변경이 예상되며 이러한 변경으로 파일 무결성 검사가 실패하지 않아야 합니다. MachineConfig 오브젝트 업데이트로 인한 파일 변경을 억제하기 위해 File Integrity Operator에서 노드 오브젝트를 감시합니다. 노드가 업데이트될 때 업데이트 기간 동안 AIDE 검사가 일시 중단됩니다. 업데이트가 완료되면 데이터베이스가 다시 초기화되고 검사가 다시 시작됩니다.

이러한 일시 중지 및 재개 논리는 노드 오브젝트 주석에 반영되므로 MachineConfig API를 통한 업데이트에만 적용됩니다.

각 FileIntegrity 오브젝트는 여러 노드에 대한 검사를 나타냅니다. 검사 자체는 데몬 세트에서 관리하는 Pod에서 수행합니다.

FileIntegrity 오브젝트를 나타내는 데몬 세트를 찾으려면 다음을 실행하십시오.

$ oc -n openshift-file-integrity get ds/aide-worker-fileintegrity

해당 데몬 세트의 Pod를 나열하려면 다음을 실행합니다.

$ oc -n openshift-file-integrity get pods -lapp=aide-worker-fileintegrity

단일 AIDE Pod의 로그를 보려면 Pod 중 하나에서 oc logs를 호출합니다.

$ oc -n openshift-file-integrity logs pod/aide-worker-fileintegrity-mr8x6

Starting the AIDE runner daemon
initializing AIDE db
initialization finished
running aide check
...

AIDE 데몬에서 생성한 구성 맵은 보관되지 않으며 File Integrity Operator에서 처리한 후 삭제됩니다. 그러나 실패 및 오류 시에는 이러한 구성 맵의 내용이 FileIntegrityNodeStatus 오브젝트가 가리키는 구성 맵에 복사됩니다.