15장. 보안 컨텍스트 제약 조건 관리
15.1. 보안 컨텍스트 제약 조건 정보
RBAC 리소스에서 사용자 액세스 권한을 제어하는 방식과 유사하게 관리자는 SCC(보안 컨텍스트 제약 조건)를 사용하여 Pod에 대한 권한을 제어할 수 있습니다. 이러한 권한에는 Pod에서 수행할 수 있는 작업과 액세스할 수 있는 리소스가 포함됩니다. Pod가 시스템에 수용되려면 일련의 조건을 함께 실행해야 하는데, SCC를 사용하여 이러한 조건을 정의할 수 있습니다.
시크릿 컨텍스트 제약 조건을 통해 관리자는 다음을 제어할 수 있습니다.
-
Pod에서
allowPrivilegedContainer플래그를 사용하여 권한 있는 컨테이너를 실행할 수 있는지 여부입니다. -
Pod가
allowPrivilegeEscalation플래그로 제한되는지 여부입니다. - 컨테이너에서 요청할 수 있는 기능
- 호스트 디렉터리를 볼륨으로 사용
- 컨테이너의 SELinux 컨텍스트
- 컨테이너 사용자 ID
- 호스트 네임스페이스 및 네트워킹 사용
-
Pod 볼륨을 보유한
FSGroup의 할당 - 허용되는 추가 그룹의 구성
- 컨테이너에 루트 파일 시스템에 대한 쓰기 액세스 권한이 필요한지 여부
- 볼륨 유형 사용
-
허용 가능한
seccomp프로필 구성
OpenShift Container Platform의 네임스페이스에 openshift.io/run-level 레이블을 설정하지 마십시오. 이 레이블은 내부 OpenShift Container Platform 구성 요소에서 Kubernetes API 서버 및 OpenShift API 서버와 같은 주요 API 그룹의 시작을 관리하는 데 사용됩니다. openshift.io/run-level 레이블이 설정된 경우 해당 네임스페이스의 Pod에 SCC가 적용되지 않으므로 해당 네임스페이스에서 실행되는 모든 워크로드에 높은 권한이 부여됩니다.
15.1.1. 기본 보안 컨텍스트 제약 조건
아래 표에 설명된 대로 클러스터에는 몇 가지 기본 SCC(보안 컨텍스트 제약 조건)가 포함되어 있습니다. OpenShift Container Platform에 Operator 또는 기타 구성 요소를 설치할 때 추가 SCC가 설치될 수 있습니다.
기본 SCC를 수정하지 마십시오. 기본 SCC를 사용자 정의하면 일부 플랫폼 Pod 배포 또는 OpenShift Container Platform이 업그레이드되는 경우 문제가 발생할 수 있습니다. 일부 버전의 OpenShift Container Platform 간에 업그레이드하는 동안 기본 SCC의 값이 기본값으로 재설정되어 해당 SCC에 대한 모든 사용자 정의가 삭제됩니다.
대신 필요에 따라 새 SCC를 만듭니다.
| 보안 컨텍스트 제약 조건 | 설명 |
|---|---|
|
|
|
|
| 모든 호스트 네임스페이스에 액세스할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트를 사용하여 pod를 실행해야 합니다. 주의 이 SCC를 사용하면 호스트 네임스페이스, 파일 시스템, PID에 액세스할 수 있습니다. 신뢰할 수 있는 pod에서만 사용해야 합니다. 주의해서 실행합니다. |
|
|
주의 이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다. |
|
| 호스트 네트워킹 및 호스트 포트를 사용할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 pod를 실행해야 합니다. 주의
컨트롤 플레인 호스트에서 추가 워크로드가 실행되는 경우 |
|
|
|
|
| Prometheus 노드 내보내기에 사용됩니다. 주의 이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다. |
|
|
|
|
|
|
|
| 모든 권한 및 호스트 기능에 대한 액세스를 허용하고 모든 사용자, 그룹, FSGroup 및 모든 SELinux 컨텍스트로 실행할 수 있습니다. 주의 이는 가장 완화된 SCC이며 클러스터 관리에만 사용해야 합니다. 주의해서 실행합니다.
참고
Pod 사양에서 |
|
| 모든 호스트 기능에 대한 액세스를 거부하고 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 Pod를 실행해야 합니다.
OpenShift Container Platform 4.10 또는 이전 버전에서 업그레이드된 클러스터에서 이 SCC는 인증된 모든 사용자가 사용할 수 있습니다. 액세스가 명시적으로 부여되지 않는 한 |
|
|
이는 새 설치에서 제공하는 가장 제한적인 SCC이며, 인증된 사용자에게 기본적으로 사용됩니다. 참고
|
15.1.2. 보안 컨텍스트 제약 조건 설정
SCC(보안 컨텍스트 제약 조건)는 pod에서 액세스할 수 있는 보안 기능을 제어하는 설정 및 전략으로 구성됩니다. 이 설정은 세 가지 범주로 분류됩니다.
| 카테고리 | 설명 |
|---|---|
| 부울로 제어 |
이 유형의 필드는 기본적으로 가장 제한적인 값으로 설정됩니다. 예를 들어, |
| 허용 가능한 설정으로 제어 | 이 유형의 필드는 해당 값이 허용되는지 확인하기 위해 설정과 대조됩니다. |
| 전략으로 제어 | 가치를 생성하는 전략이 있는 항목에서는 다음을 제공합니다.
|
CRI-O에는 Pod의 각 컨테이너에 허용되는 다음 기본 기능 목록이 있습니다.
-
CHOWN -
DAC_OVERRIDE -
FSETID -
FOWNER -
SETGID -
SETUID -
SETPCAP -
NET_BIND_SERVICE -
KILL
컨테이너에서는 이 기본 목록의 기능을 사용하지만 Pod 매니페스트 작성자는 추가 기능을 요청하거나 일부 기본 동작을 제거하여 목록을 변경할 수 있습니다. allowedCapabilities,defaultAddCapabilities, requiredDropCapabilities 매개변수를 사용하여 Pod에서 이러한 요청을 제어합니다. 이러한 매개변수를 사용하면 각 컨테이너에 추가해야 하는 기능, 각 컨테이너에서 금지 또는 삭제해야 하는 기능을 지정할 수 있습니다.
requiredDropCapabilities 매개변수를 ALL 로 설정하여 컨테이너에서 모든 capabilites를 삭제할 수 있습니다. restricted-v2 SCC가 수행하는 작업입니다.
15.1.3. 보안 컨텍스트 제약 조건 전략
RunAsUser
MustRunAs-runAsUser를 구성해야 합니다. 구성된runAsUser를 기본값으로 사용합니다. 구성된runAsUser에 대해 검증합니다.MustRunAs스니펫 예... runAsUser: type: MustRunAs uid: <id> ...
MustRunAsRange- 사전 할당된 값을 사용하지 않는 경우 최솟값과 최댓값을 정의해야 합니다. 최솟값을 기본값으로 사용합니다. 전체 허용 범위에 대해 검증합니다.MustRunAsRange스니펫 예... runAsUser: type: MustRunAsRange uidRangeMax: <maxvalue> uidRangeMin: <minvalue> ...
MustRunAsNonRoot- Pod를 0이 아닌runAsUser를 사용하여 제출하거나 Pod의 이미지에USER지시문이 정의되어 있어야 합니다. 기본값이 제공되지 않습니다.MustRunAsNonRoot스니펫 예... runAsUser: type: MustRunAsNonRoot ...
RunAsAny- 기본값이 제공되지 않습니다. 모든runAsUser를 지정할 수 있습니다.RunAsAny조각의 예... runAsUser: type: RunAsAny ...
SELinuxContext
-
MustRunAs- 사전 할당된 값을 사용하지 않는 경우seLinuxOptions를 구성해야 합니다.seLinuxOptions를 기본값으로 사용합니다.seLinuxOptions에 대해 검증합니다. -
RunAsAny- 기본값이 제공되지 않습니다. 모든seLinuxOptions를 지정할 수 있습니다.
SupplementalGroups
-
MustRunAs- 사전 할당된 값을 사용하지 않는 경우 범위를 하나 이상 지정해야 합니다. 첫 번째 범위의 최솟값을 기본값으로 사용합니다. 모든 범위에 대해 검증합니다. -
RunAsAny- 기본값이 제공되지 않습니다. 임의의supplementalGroups을 지정할 수 있습니다.
FSGroup
-
MustRunAs- 사전 할당된 값을 사용하지 않는 경우 범위를 하나 이상 지정해야 합니다. 첫 번째 범위의 최솟값을 기본값으로 사용합니다. 첫 번째 범위의 첫 번째 ID에 대해 검증합니다. -
RunAsAny- 기본값이 제공되지 않습니다.fsGroupID를 지정할 수 있습니다.
15.1.4. 볼륨 제어
SCC의 volumes 필드를 설정하여 특정 볼륨 유형의 사용을 제어할 수 있습니다. 이 필드에 허용되는 값은 볼륨 생성 시 정의되는 볼륨 소스에 해당합니다.
-
awsElasticBlockStore -
azureDisk -
azureFile -
cephFS -
cinder -
configMap -
downwardAPI -
emptyDir -
fc -
flexVolume -
flocker -
gcePersistentDisk -
ephemeral -
gitRepo -
glusterfs -
hostPath -
iscsi -
nfs -
persistentVolumeClaim -
photonPersistentDisk -
portworxVolume -
projected -
quobyte -
rbd -
scaleIO -
secret -
storageos -
vsphereVolume - * (모든 볼륨 유형의 사용을 허용하는 특수 값)
-
none(모든 볼륨 유형의 사용을 허용하지 않는 특수 값입니다. 이전 버전과의 호환성을 위해서만 존재합니다.)
새 SCC에 허용되는 볼륨의 최소 권장 집합은 configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, projected입니다.
OpenShift Container Platform의 각 릴리스에 새로운 유형이 추가되므로 허용되는 볼륨 유형 목록은 포괄적이지 않습니다.
이전 버전과의 호환성을 위해 allowHostDirVolumePlugin을 사용하면 volumes 필드의 설정을 덮어씁니다. 예를 들어, allowHostDirVolumePlugin이 false로 설정되어 있지만 volumes 필드에서 허용되는 경우 volumes에서 hostPath 값이 제거됩니다.
15.1.5. 승인 제어
SCC를 통한 허용 제어를 사용하면 사용자에게 부여된 기능을 기반으로 리소스 생성을 제어할 수 있습니다.
SCC 측면에서는 허용 컨트롤러가 컨텍스트에서 사용 가능한 사용자 정보를 검사하여 적절한 SCC 집합을 검색할 수 있음을 의미합니다. 이 경우 Pod에 운영 환경에 대한 요청을 하거나 Pod에 적용할 일련의 제약 조건을 생성할 수 있는 권한이 부여됩니다.
허용 작업에서 Pod를 승인하는 데 사용하는 SCC 집합은 사용자 ID 및 사용자가 속하는 그룹에 따라 결정됩니다. 또한 Pod에서 서비스 계정을 지정하는 경우, 허용된 SCC 집합에 서비스 계정에 액세스할 수 있는 모든 제약 조건이 포함됩니다.
배포와 같은 워크로드 리소스를 생성할 때 서비스 계정만 SCC를 찾고 Pod가 생성될 때 Pod를 허용하는 데 사용됩니다.
허용 작업에서는 다음 방법을 사용하여 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가 실패할 수 있습니다.
15.1.6. 보안 컨텍스트 제약 조건 우선순위 지정
SCC(보안 컨텍스트 제약 조건)에는 승인 컨트롤러의 요청을 확인할 때 순서에 영향을 주는 우선순위 필드가 있습니다.
우선순위 0 은 가능한 가장 낮은 우선 순위입니다. nil 우선순위는 0 또는 가장 낮은 우선순위로 간주됩니다. 정렬 시 우선순위가 높은 SCC가 집합의 앞쪽으로 이동합니다.
사용 가능한 전체 SCC 집합이 결정되면 SCC가 다음과 같은 방식으로 정렬됩니다.
- 우선순위가 가장 높은 SCC가 먼저 정렬됩니다.
- 우선순위가 동일한 경우 SCC는 가장 제한적인 것에서 최소 제한으로 정렬됩니다.
- 우선순위와 제한이 모두 동일한 경우 SCC는 이름별로 정렬됩니다.
기본적으로 클러스터 관리자에게 부여되는 anyuid SCC는 SCC 집합에서 우선순위가 부여됩니다. 이를 통해 클러스터 관리자는 Pod의 SecurityContext 에 RunAsUser 를 지정하여 모든 사용자로 Pod를 실행할 수 있습니다.
