4.2.5.5. 허용
SCC를 통한 허용 제어를 사용하면 사용자에게 부여된 기능을 기반으로 리소스 생성을 제어할 수 있습니다.
SCC 측면에서는 허용 컨트롤러가 컨텍스트에서 사용 가능한 사용자 정보를 검사하여 적절한 SCC 집합을 검색할 수 있음을 의미합니다. 이 경우 Pod에 운영 환경에 대한 요청을 하거나 Pod에 적용할 일련의 제약 조건을 생성할 수 있는 권한이 부여됩니다.
허용 작업에서 Pod를 승인하는 데 사용하는 SCC 집합은 사용자 ID 및 사용자가 속하는 그룹에 따라 결정됩니다. 또한 Pod에서 서비스 계정을 지정하는 경우, 허용된 SCC 집합에 서비스 계정에 액세스할 수 있는 모든 제약 조건이 포함됩니다.
허용 작업에서는 다음 방법을 사용하여 Pod에 대한 최종 보안 컨텍스트를 생성합니다.
- 사용 가능한 모든 SCC를 검색합니다.
- 요청에 지정되지 않은 보안 컨텍스트 설정에 대한 필드 값을 생성합니다.
- 사용 가능한 제약 조건에 대해 최종 설정을 검증합니다.
일치하는 제약 조건 집합이 있는 경우 Pod가 승인됩니다. 요청을 SCC와 일치시킬 수 없는 경우 Pod가 거부됩니다.
Pod는 SCC에 대해 모든 필드를 검증해야 합니다. 다음은 검증이 필요한 필드 중 단 2개의 예입니다.
이러한 예는 사전 할당된 값을 사용하는 전략과 관련이 있습니다.
MustRunAs의 FSGroup SCC 전략
Pod에서 fsGroup ID를 정의하는 경우 해당 ID는 기본 fsGroup ID와 같아야 합니다. 그렇지 않으면 해당 SCC에서 Pod를 검증하지 않고 다음 SCC를 평가합니다.
SecurityContextConstraints.fsGroup 필드에 값 RunAsAny가 있고 Pod 사양에서 Pod.spec.securityContext.fsGroup을 생략하는 경우, 이 필드는 유효한 것으로 간주됩니다. 유효성을 확인하는 동안 다른 SCC 설정에서 다른 Pod 필드를 거부하여 Pod가 실패할 수 있습니다.
MustRunAs의 SupplementalGroups SCC 전략
Pod 사양에서 하나 이상의 supplementalGroups ID를 정의하는 경우, Pod의 ID는 네임스페이스의 openshift.io/sa.scc.supplemental-groups 주석에 있는 ID 중 하나와 같아야 합니다. 그렇지 않으면 해당 SCC에서 Pod를 검증하지 않고 다음 SCC를 평가합니다.
SecurityContextConstraints.supplementalGroups 필드에 값 RunAsAny가 있고 Pod 사양에서 Pod.spec.securityContext.supplementalGroups를 생략하는 경우, 이 필드는 유효한 것으로 간주됩니다. 유효성을 확인하는 동안 다른 SCC 설정에서 다른 Pod 필드를 거부하여 Pod가 실패할 수 있습니다.
4.2.5.5.1. SCC 우선순위 지정
SCC에는 허용 컨트롤러의 요청을 검증할 때 순서에 영향을 미치는 우선순위 필드가 있습니다. 정렬 시 우선순위가 높은 SCC가 집합의 앞쪽으로 이동합니다. 사용 가능한 SCC 전체 집합이 결정되면 다음 순서에 따라 정렬됩니다.
- 우선순위가 가장 높은 SCC가 맨 앞에 오고, NIL은 우선순위 0으로 간주됩니다
- 우선순위가 동일한 경우, 가장 제한적인 SCC에서 가장 덜 제한적인 SCC 순서대로 정렬됩니다.
- 우선순위와 제한이 모두 같은 경우 SCC는 이름순으로 정렬됩니다.
기본적으로 클러스터 관리자에게 부여된 anyuid SCC에는 SCC 세트에서 우선 순위가 부여됩니다. 이를 통해 클러스터 관리자는 Pod의 SecurityContext에 RunAsUser를 지정하지 않고도 모든 사용자로 Pod를 실행할 수 있습니다. 원하는 경우 관리자는 RunAsUser를 계속 지정할 수도 있습니다.
