2.9. 컨테이너 배포

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

예를 들어 코어, 미들웨어 및 애플리케이션의 세 가지 컨테이너 이미지 계층을 사용하여 애플리케이션을 빌드합니다. 핵심 이미지에서 문제가 발견되고 해당 이미지가 다시 빌드됩니다. 빌드가 완료되면 이미지가 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을 활용하면 최신 수정 사항을 통합하기 위해 애플리케이션을 재빌드하고 테스트한 다음 환경 내 모든 위치에 배포되었는지 확인하는 프로세스를 자동화할 수 있습니다.