지원콘솔개발자평가판 시작연락처

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를 만듭니다.

표 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를 실행하는 워크로드는 클러스터에 효과적으로 루팅되므로 신뢰해야 합니다.

node-exporter

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

주의

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

nonroot

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

privileged

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

주의

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

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

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

Pod 사양에 privileged: true 를 설정하면 권한 있는 SCC가 반드시 선택되지는 않습니다. PrivilegedContainer: true를 허용하고 사용자가 사용할 권한이 있는 경우 우선순위가 가장 높은 SCC를 선택합니다.

restricted

모든 호스트 기능에 대한 액세스를 거부하고 네임스페이스에 할당된 UID 및 SELinux 컨텍스트로 Pod를 실행해야 합니다. 이는 새 설치에서 제공하는 가장 제한적인 SCC이며 기본적으로 인증된 사용자에게 사용됩니다.

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

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

restricted SCC는 기본적으로 시스템과 함께 제공되는 SCC의 가장 제한 사항입니다. 그러나 더 제한적인 사용자 지정 SCC를 생성할 수 있습니다. 예를 들어 readOnlyRootFS 를 true 로 제한하고 PrivilegeEscalation을 false 로 허용하는 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의 이러한 요청을 제어하고, 요청 가능한 기능, 각 컨테이너에 추가해야 하는 기능, 금지해야 하는 기능을 지정할 수 있습니다.

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 필드를 설정하여 특정 볼륨 유형의 사용을 제어할 수 있습니다. 이 필드에 허용되는 값은 볼륨 생성 시 정의되는 볼륨 소스에 해당합니다.

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

  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(보안 컨텍스트 제약 조건)에는 승인 컨트롤러의 요청을 확인할 때 순서에 영향을 주는 우선순위 필드가 있습니다. 정렬 시 우선순위가 높은 SCC가 집합의 앞쪽으로 이동합니다. 사용 가능한 SCC 전체 집합이 결정되면 다음 순서에 따라 정렬됩니다.

  1. 우선순위가 가장 높은 SCC가 맨 앞에 오고, NIL은 우선순위 0으로 간주됩니다
  2. 우선순위가 동일한 경우, 가장 제한적인 SCC에서 가장 덜 제한적인 SCC 순서대로 정렬됩니다.
  3. 우선순위와 제한이 모두 같은 경우 SCC는 이름순으로 정렬됩니다.

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

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.