5.9. Pod 보안 승인 준수
Pod 보안 허용 은 Kubernetes Pod 보안 표준을 구현한 것입니다. Pod 보안 허용 은 Pod의 동작을 제한합니다. 전역 또는 네임스페이스 수준에서 정의된 Pod 보안 승인을 준수하지 않는 Pod는 클러스터에 허용되지 않으며 실행할 수 없습니다.
Operator 프로젝트에서 에스컬레이션된 권한을 실행할 필요가 없는 경우 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 워크로드가 실행되도록 할 수 있습니다. Operator 프로젝트를 실행하려면 에스컬레이션된 권한이 필요한 경우 다음과 같은 보안 컨텍스트 구성을 설정해야 합니다.
- Operator의 네임스페이스에 허용되는 Pod 보안 승인 수준
- 워크로드 서비스 계정에 허용되는 SCC(보안 컨텍스트 제약 조건)
자세한 내용은 Pod 보안 승인 이해 및 관리를 참조하십시오.
5.9.1. Pod 보안 표준을 사용한 보안 컨텍스트 제약 조건 동기화
OpenShift Container Platform에는 Kubernetes Pod 보안 승인이 포함되어 있습니다. 전체적으로 권한 프로파일이 적용되며 제한된 프로필은 경고 및 감사에 사용됩니다.
글로벌 Pod 보안 승인 제어 구성 외에도 Pod 보안 허용 제어 경고 및 감사 레이블을 지정된 네임스페이스에 있는 서비스 계정의 SCC 권한에 따라 네임스페이스에 적용하는 컨트롤러가 있습니다.
클러스터 페이로드의 일부로 정의된 네임스페이스에는 Pod 보안 승인 동기화가 영구적으로 비활성화되어 있습니다. 필요에 따라 다른 네임스페이스에서 Pod 보안 승인 동기화를 활성화할 수 있습니다. 사용자 생성 openshift-* 네임스페이스에 Operator가 설치된 경우 CSV(클러스터 서비스 버전)가 네임스페이스에 생성된 후 기본적으로 동기화가 설정됩니다.
컨트롤러는 각 네임스페이스에서 보안 컨텍스트 제약 조건을 사용하도록 ServiceAccount 오브젝트 권한을 검사합니다. SCC(보안 컨텍스트 제약 조건)는 필드 값을 기반으로 Pod 보안 프로필에 매핑됩니다. 컨트롤러는 이러한 변환된 프로필을 사용합니다. Pod 보안 허용 경고 및 감사 레이블은 Pod가 생성될 때 경고 및 감사 로깅을 방지하기 위해 네임스페이스에 있는 가장 권한 있는 Pod 보안 프로필로 설정됩니다.
네임스페이스 레이블 지정은 네임스페이스 로컬 서비스 계정 권한 고려를 기반으로 합니다.
Pod를 직접 적용하면 Pod를 실행하는 사용자의 SCC 권한을 사용할 수 있습니다. 그러나 사용자 권한은 자동 레이블 지정 중에 고려되지 않습니다.
5.9.2. 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 Operator 워크로드가 실행되도록 합니다.
Operator 프로젝트를 다양한 배포 및 환경에서 실행할 수 있도록 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 실행하도록 Operator의 워크로드를 구성합니다.
runAsUser 필드를 비워 두어야 합니다. 이미지에 특정 사용자가 필요한 경우 제한된 SCC(보안 컨텍스트 제약 조건) 및 제한된 Pod 보안 적용에서 실행할 수 없습니다.
절차
제한된Pod 보안 수준으로 설정된 네임스페이스에서 실행되도록 Operator 워크로드를 구성하려면 다음 예와 유사한 Operator의 네임스페이스 정의를 편집합니다.중요Operator의 네임스페이스 정의에 seccomp 프로필을 설정하는 것이 좋습니다. 그러나 OpenShift Container Platform 4.10에서는 seccomp 프로필 설정이 지원되지 않습니다.
OpenShift Container Platform 4.11 이상에서만 실행해야 하는 Operator 프로젝트의 경우 다음 예와 유사한 Operator의 네임스페이스 정의를 편집합니다.
config/manager/manager.yaml예제 파일... spec: securityContext: seccompProfile: type: RuntimeDefault 1 runAsNonRoot: true containers: - name: <operator_workload_container> securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL ...- 1
- seccomp 프로필 유형을
RuntimeDefault로 설정하면 SCC는 기본적으로 네임스페이스의 Pod 보안 프로파일로 설정됩니다.
OpenShift Container Platform 4.10에서도 실행해야 하는 Operator 프로젝트의 경우 다음 예와 유사한 Operator의 네임스페이스 정의를 편집합니다.
config/manager/manager.yaml예제 파일... spec: securityContext: 1 runAsNonRoot: true containers: - name: <operator_workload_container> securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL ...- 1
- seccomp 프로필 유형을 설정되지 않은 상태로 두면 Operator 프로젝트가 OpenShift Container Platform 4.10에서 실행될 수 있습니다.
추가 리소스
5.9.3. 에스컬레이션된 권한이 필요한 Operator 워크로드에 대한 Pod 보안 승인 관리
Operator 프로젝트에서 실행할 수 있는 권한을 에스컬레이션해야 하는 경우 Operator의 CSV(클러스터 서비스 버전)를 편집해야 합니다.
절차
다음 예와 유사하게 보안 컨텍스트 구성을 Operator CSV에서 필요한 권한 수준으로 설정합니다.
네트워크 관리자 권한이 있는 <
;operator_name>.clusterserviceversion.yaml파일의 예... containers: - name: my-container securityContext: allowPrivilegeEscalation: false capabilities: add: - "NET_ADMIN" ...다음 예와 유사하게 Operator의 워크로드가 필요한 SCC(보안 컨텍스트 제약 조건)를 사용하도록 허용하는 서비스 계정 권한을 설정합니다.
예:
<operator_name>.clusterserviceversion.yaml파일... install: spec: clusterPermissions: - rules: - apiGroups: - security.openshift.io resourceNames: - privileged resources: - securitycontextconstraints verbs: - use serviceAccountName: default ...Operator의 CSV 설명을 편집하여 Operator 프로젝트에 다음 예와 유사한 에스컬레이션 권한이 필요한 이유를 설명합니다.
예:
<operator_name>.clusterserviceversion.yaml파일... spec: apiservicedefinitions:{} ... description: The <operator_name> requires a privileged pod security admission label set on the Operator's namespace. The Operator's agents require escalated permissions to restart the node if the node needs remediation.
