15장. 보안 컨텍스트 제약 조건 관리

OpenShift Container Platform에서는 SCC(보안 컨텍스트 제약 조건)를 사용하여 클러스터의 Pod 권한을 제어할 수 있습니다.

기본 SCC는 설치 중에 그리고 일부 Operator 또는 기타 구성 요소를 설치할 때 생성됩니다. 클러스터 관리자는 OpenShift CLI(oc)를 사용하여 고유한 SCC를 생성할 수도 있습니다.

중요

기본 SCC를 수정하지 마십시오. 기본 SCC를 사용자 정의하면 일부 플랫폼 Pod 배포 또는 OpenShift Container Platform이 업그레이드되는 경우 문제가 발생할 수 있습니다. 또한 일부 클러스터 업그레이드 중에 기본 SCC 값이 기본값으로 재설정되므로 해당 SCC에 대한 모든 사용자 정의를 삭제합니다.

기본 SCC를 수정하는 대신 필요에 따라 자체 SCC를 생성하고 수정합니다. 자세한 단계는 보안 컨텍스트 제약 조건 생성 을 참조하십시오.

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이 업그레이드되는 경우 문제가 발생할 수 있습니다. 또한 일부 클러스터 업그레이드 중에 기본 SCC 값이 기본값으로 재설정되므로 해당 SCC에 대한 모든 사용자 정의를 삭제합니다.

기본 SCC를 수정하는 대신 필요에 따라 자체 SCC를 생성하고 수정합니다. 자세한 단계는 보안 컨텍스트 제약 조건 생성 을 참조하십시오.

표 15.1. 기본 보안 컨텍스트 제약 조건

보안 컨텍스트 제약 조건설명

anyuid

restricted SCC의 모든 기능을 제공하지만 사용자는 모든 UID 및 GID로 실행할 수 있습니다.

hostaccess

모든 호스트 네임스페이스에 액세스할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트를 사용하여 pod를 실행해야 합니다.

주의

이 SCC를 사용하면 호스트에서 네임스페이스, 파일 시스템 및 PID에 액세스할 수 있습니다. 신뢰할 수 있는 pod에서만 사용해야 합니다. 주의해서 실행합니다.

hostmount-anyuid

restricted SCC의 모든 기능을 제공하지만 호스트는 시스템의 모든 UID 및 GID로 마운트하고 실행할 수 있습니다.

주의

이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다.

hostnetwork

호스트 네트워킹 및 호스트 포트를 사용할 수 있지만 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 pod를 실행해야 합니다.

주의

컨트롤 플레인 호스트에서 추가 워크로드가 실행되는 경우 hostnetwork에 대한 액세스를 제공할 때 주의하십시오. 컨트롤 플레인 호스트에서 hostnetwork를 실행하는 워크로드는 클러스터에 효과적으로 루팅되므로 신뢰해야 합니다.

hostnetwork-v2

hostnetwork SCC와 마찬가지로 다음과 같은 차이점이 있습니다.

  • ALL 기능은 컨테이너에서 삭제됩니다.
  • NET_BIND_SERVICE 기능을 명시적으로 추가할 수 있습니다.
  • seccompProfile 은 기본적으로 runtime/default 로 설정됩니다.
  • 보안 컨텍스트에서 allowPrivilegeEscalation을 설정하지 않거나 false로 설정해야 합니다.

node-exporter

Prometheus 노드 내보내기에 사용됩니다.

주의

이 SCC를 사용하면 UID 0을 포함하여 모든 UID로 호스트 파일 시스템에 액세스할 수 있습니다. 주의해서 실행합니다.

nonroot

restricted SCC의 모든 기능을 제공하지만 사용자는 루트 이외의 UID로 실행할 수 있습니다. 사용자는 UID를 지정하거나 컨테이너 런타임의 매니페스트에 지정해야 합니다.

nonroot-v2

root가 아닌 SCC와 마찬가지로 다음과 같은 차이점이 있습니다.

  • ALL 기능은 컨테이너에서 삭제됩니다.
  • NET_BIND_SERVICE 기능을 명시적으로 추가할 수 있습니다.
  • seccompProfile 은 기본적으로 runtime/default 로 설정됩니다.
  • 보안 컨텍스트에서 allowPrivilegeEscalation을 설정하지 않거나 false로 설정해야 합니다.

privileged

모든 권한 및 호스트 기능에 대한 액세스를 허용하고 모든 사용자, 그룹, FSGroup 및 모든 SELinux 컨텍스트로 실행할 수 있습니다.

주의

이는 가장 완화된 SCC이며 클러스터 관리에만 사용해야 합니다. 주의해서 실행합니다.

권한 있는 SCC를 사용하면 다음을 수행할 수 있습니다.

  • 사용자가 권한 있는 Pod 실행
  • Pod에서 호스트 디렉터리를 볼륨으로 마운트
  • Pod를 모든 사용자로 실행
  • Pod를 모든 MCS 라벨로 실행
  • Pod에서 호스트의 IPC 네임스페이스 사용
  • Pod에서 호스트의 PID 네임스페이스 사용
  • Pod에서 모든 FSGroup 사용
  • Pod에서 추가 그룹 사용
  • Pod에서 seccomp 프로필 사용
  • Pod에서 모든 기능 요청
참고

Pod 사양에서 privileged: true 를 설정해도 권한 있는 SCC를 선택할 필요는 없습니다. 권한이 있는 SCC: true 가 허용되고 사용자가 사용할 권한이 있으면 우선순위가 가장 높습니다.

restricted

모든 호스트 기능에 대한 액세스를 거부하고 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 Pod를 실행해야 합니다.

제한된 SCC의 경우 다음을 수행합니다.

  • Pod가 권한에 따라 실행되지 않도록 합니다.
  • Pod에서 호스트 디렉터리 볼륨을 마운트할 수 없는지 확인합니다.
  • 미리 할당된 UID 범위에서 Pod를 사용자로 실행해야 합니다.
  • Pod를 사전 할당된 MCS 라벨로 실행해야 합니다.
  • Pod를 사전 할당된 FSGroup으로 실행해야 합니다.
  • Pod에서 추가 그룹을 사용하도록 허용

OpenShift Container Platform 4.10 또는 이전 버전에서 업그레이드된 클러스터에서 이 SCC는 인증된 모든 사용자가 사용할 수 있습니다. 액세스 권한이 명시적으로 부여되지 않는 한 제한된 SCC는 새로운 OpenShift Container Platform 4.11 이상의 사용자가 더 이상 사용할 수 없습니다.

restricted-v2

제한된 SCC와 유사하지만 다음과 같은 차이점이 있습니다.

  • ALL 기능은 컨테이너에서 삭제됩니다.
  • NET_BIND_SERVICE 기능을 명시적으로 추가할 수 있습니다.
  • seccompProfile 은 기본적으로 runtime/default 로 설정됩니다.
  • 보안 컨텍스트에서 allowPrivilegeEscalation을 설정하지 않거나 false로 설정해야 합니다.

이는 새 설치에서 제공하는 가장 제한적인 SCC이며 인증된 사용자에게 기본적으로 사용됩니다.

참고

restricted-v2 SCC는 기본적으로 시스템에 포함된 SCC를 가장 엄격하게 제한합니다. 그러나 제한적인 사용자 정의 SCC를 생성할 수 있습니다. 예를 들어 readOnlyRootFilesystem 을 true 로 제한하는 SCC를 생성할 수 있습니다.

15.1.2. 보안 컨텍스트 제약 조건 설정

SCC(보안 컨텍스트 제약 조건)는 pod에서 액세스할 수 있는 보안 기능을 제어하는 설정 및 전략으로 구성됩니다. 이 설정은 세 가지 범주로 분류됩니다.

카테고리설명

부울로 제어

이 유형의 필드는 기본적으로 가장 제한적인 값으로 설정됩니다. 예를 들어, AllowPrivilegedContainer는 값이 지정되지 않은 경우 항상 false로 설정됩니다.

허용 가능한 설정으로 제어

이 유형의 필드는 해당 값이 허용되는지 확인하기 위해 설정과 대조됩니다.

전략으로 제어

가치를 생성하는 전략이 있는 항목에서는 다음을 제공합니다.

  • 가치를 생성하는 메커니즘
  • 지정된 값이 허용된 값 집합에 속하도록 하는 메커니즘

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 - 기본값이 제공되지 않습니다. fsGroup ID를 지정할 수 있습니다.

15.1.4. 볼륨 제어

SCC의 volumes 필드를 설정하여 특정 볼륨 유형의 사용을 제어할 수 있습니다.

이 필드에 허용되는 값은 볼륨 생성 시 정의되는 볼륨 소스에 해당합니다.

새 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에 대한 최종 보안 컨텍스트를 생성합니다.

  1. 사용 가능한 모든 SCC를 검색합니다.
  2. 요청에 지정되지 않은 보안 컨텍스트 설정에 대한 필드 값을 생성합니다.
  3. 사용 가능한 제약 조건에 대해 최종 설정을 검증합니다.

일치하는 제약 조건 집합이 있는 경우 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가 다음과 같은 방식으로 정렬됩니다.

  1. 우선순위가 가장 높은 SCC가 먼저 정렬됩니다.
  2. 우선순위가 동일한 경우 SCC는 가장 제한적인 것에서 최소 제한으로 정렬됩니다.
  3. 우선순위와 제한이 모두 동일한 경우 SCC는 이름별로 정렬됩니다.

기본적으로 클러스터 관리자에게 부여되는 anyuid SCC는 SCC 집합에서 우선순위가 부여됩니다. 이를 통해 클러스터 관리자는 Pod의 SecurityContext 에 RunAsUser 를 지정하여 모든 사용자로 Pod를 실행할 수 있습니다.