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를 실행해야 합니다. 이는 새 설치에서 제공하는 가장 제한적인 SCC이며 기본적으로 인증된 사용자에게 사용됩니다.
참고
restricted SCC는 기본적으로 시스템과 함께 제공되는 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의 이러한 요청을 제어하고, 요청 가능한 기능, 각 컨테이너에 추가해야 하는 기능, 금지해야 하는 기능을 지정할 수 있습니다.
15.1.3. 보안 컨텍스트 제약 조건 전략
RunAsUser
-
MustRunAs
-runAsUser
를 구성해야 합니다. 구성된runAsUser
를 기본값으로 사용합니다. 구성된runAsUser
에 대해 검증합니다. -
MustRunAsRange
- 사전 할당된 값을 사용하지 않는 경우 최솟값과 최댓값을 정의해야 합니다. 최솟값을 기본값으로 사용합니다. 전체 허용 범위에 대해 검증합니다. -
MustRunAsNonRoot
- Pod를 0이 아닌runAsUser
를 사용하여 제출하거나 Pod의 이미지에USER
지시문이 정의되어 있어야 합니다. 기본값이 제공되지 않습니다. -
RunAsAny
- 기본값이 제공되지 않습니다. 모든runAsUser
를 지정할 수 있습니다.
SELinuxContext
-
MustRunAs
- 사전 할당된 값을 사용하지 않는 경우seLinuxOptions
를 구성해야 합니다.seLinuxOptions
를 기본값으로 사용합니다.seLinuxOptions
에 대해 검증합니다. -
RunAsAny
- 기본값이 제공되지 않습니다. 모든seLinuxOptions
를 지정할 수 있습니다.
SupplementalGroups
-
MustRunAs
- 사전 할당된 값을 사용하지 않는 경우 범위를 하나 이상 지정해야 합니다. 첫 번째 범위의 최솟값을 기본값으로 사용합니다. 모든 범위에 대해 검증합니다. -
RunAsAny
- 기본값이 제공되지 않습니다. 임의의supplementalGroups
을 지정할 수 있습니다.
FSGroup
-
MustRunAs
- 사전 할당된 값을 사용하지 않는 경우 범위를 하나 이상 지정해야 합니다. 첫 번째 범위의 최솟값을 기본값으로 사용합니다. 첫 번째 범위의 첫 번째 ID에 대해 검증합니다. -
RunAsAny
- 기본값이 제공되지 않습니다.fsGroup
ID를 지정할 수 있습니다.
15.1.4. 볼륨 제어
SCC의 volumes
필드를 설정하여 특정 볼륨 유형의 사용을 제어할 수 있습니다. 이 필드에 허용되는 값은 볼륨 생성 시 정의되는 볼륨 소스에 해당합니다.
-
awsElasticBlockStore
-
azureDisk
-
azureFile
-
cephFS
-
Cinder
-
configMap
-
downwardAPI
-
emptyDir
-
fc
-
flexVolume
-
flocker
-
gcePersistentDisk
-
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 집합에 서비스 계정에 액세스할 수 있는 모든 제약 조건이 포함됩니다.
허용 작업에서는 다음 방법을 사용하여 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(보안 컨텍스트 제약 조건)에는 승인 컨트롤러의 요청을 확인할 때 순서에 영향을 주는 우선순위 필드가 있습니다. 정렬 시 우선순위가 높은 SCC가 집합의 앞쪽으로 이동합니다. 사용 가능한 SCC 전체 집합이 결정되면 다음 순서에 따라 정렬됩니다.
- 우선순위가 가장 높은 SCC가 맨 앞에 오고, NIL은 우선순위 0으로 간주됩니다
- 우선순위가 동일한 경우, 가장 제한적인 SCC에서 가장 덜 제한적인 SCC 순서대로 정렬됩니다.
- 우선순위와 제한이 모두 같은 경우 SCC는 이름순으로 정렬됩니다.
기본적으로 클러스터 관리자에게 부여되는 anyuid
SCC는 SCC 집합에서 우선순위가 부여됩니다. 이를 통해 클러스터 관리자는 Pod의 SecurityContext
에 RunAsUser
를 지정하지 않고도 모든 사용자로 Pod를 실행할 수 있습니다. 원하는 경우 관리자는 RunAsUser
를 계속 지정할 수도 있습니다.