이 문서는 소스 OpenShift 클러스터에 정의된 OpenShift 보안 컨텍스트 제약조건(SCC)에서 대상 GKE 클러스터로 보안 정책 마이그레이션을 계획하는 데 도움이 됩니다. 이 구현은 정책 컨트롤러 제약조건을 사용하여 마이그레이션된 정책을 대상 클러스터에 정의합니다.
이 문서에서는 개발자가 Google Cloud로 컨테이너 마이그레이션: OpenShift에서 GKE Enterprise로 마이그레이션에 익숙하다고 가정합니다. 여기서는 개발자가 OpenShift 및 보안 컨텍스트 제약조건에 익숙하고 소스 OpenShift 클러스터와 대상 GKE 클러스터에 대한 액세스 권한을 가지고 있다고 가정합니다.
이 문서는 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부입니다. 시리즈 개요는 Google Cloud로 마이그레이션: 마이그레이션 경로 선택을 참조하세요.
이 문서는 컨테이너를 Google Cloud로 마이그레이션하는 방법을 설명하는 시리즈의 일부입니다.
- 컨테이너를 Google Cloud로 마이그레이션: Kubernetes를 Google Kubernetes Engine(GKE)으로 마이그레이션
- Google Cloud로 컨테이너 마이그레이션: OpenShift에서 GKE Enterprise로 마이그레이션
- 컨테이너를 Google Cloud로 마이그레이션: OpenShift 프로젝트를 GKE Enterprise로 마이그레이션
- OpenShift에서 GKE Enterprise로 마이그레이션: OpenShift SCC를 정책 컨트롤러 제약조건으로 마이그레이션(이 문서)
이 문서는 OpenShift SCC를 GKE Enterprise로 마이그레이션하려는 경우에 유용합니다. 이 문서는 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에도 유용합니다.
이 문서에서는 Google Cloud로 마이그레이션: 시작하기, Google Cloud로 컨테이너 마이그레이션: Kubernetes를 GKE로 마이그레이션, Google Cloud로 컨테이너 마이그레이션: OpenShift에서 GKE Enterprise로 마이그레이션, GKE 네트워킹 권장사항에 설명된 개념을 사용합니다. 해당되는 경우 이러한 문서 링크를 포함합니다.
OpenShift SCC
SCC는 포드에서 수행할 수 있는 작업과 노드에서 액세스할 수 있는 리소스를 지정하는 포드의 정책을 정의하는 데 사용되는 OpenShift 관련 리소스입니다. 포드를 만들도록 API 요청을 실행하면 SCC는 SCC를 통해 정의된 정책 집합과 비교하여 프로세스 권한 측면에서 포드 요청을 평가합니다. SCC는 요청을 평가하여 구성된 정책에 따라 포드 실행을 허용하거나 허용하지 않습니다. OpenShift SCC에 대한 자세한 내용은 보안 컨텍스트 제약조건 관리를 참조하세요.
기본 OpenShift SCC
OpenShift 4.x 클러스터에는 Red Hat의 Managing SCCs in OpenShift 블로그 게시물에 설명된 기본 SCC 집합이 포함되어 있습니다.
구성 동기화 및 정책 컨트롤러
이 섹션에서는 구성 동기화와 정책 컨트롤러를 설명합니다. 이 섹션에서는 관련 문서와 이 문서의 뒷부분에서 설명하는 마이그레이션 태스크를 수행하도록 정책 컨트롤러를 설정하는 안내에 대한 링크를 제공합니다.
구성 동기화
구성 동기화를 사용하면 공통 Git 호환 저장소를 사용하여 모든 GKE Enterprise 관리형 Kubernetes 클러스터에 적용되는 모든 리소스의 구성을 중앙에서 정의할 수 있습니다. 이 구성을 여러 클러스터에 적용합니다.
정책 컨트롤러
정책 컨트롤러는 중앙에서 정의된 정책에 따라 클러스터 규정 준수를 확인, 감사, 시행하는 Kubernetes 동적 승인 컨트롤러입니다. 정책 컨트롤러는 Open Policy Agent(OPA) Gatekeeper 오픈소스 프로젝트를 기반으로 합니다.
구성 동기화 및 정책 컨트롤러 설정
OpenShift SCC를 미러링하는 보안 정책을 구현하려면 각 대상 클러스터에 구성 동기화 및 정책 컨트롤러 구성요소를 사용 설정합니다. 이 섹션에서는 이러한 구성요소를 설정하는 방법을 설명합니다. 이 문서 뒷부분의 OpenShift SCC 마이그레이션 섹션에서는 정책 컨트롤러 제약조건 템플릿을 사용하여 보안 정책을 구현하는 방법을 설명합니다.
정책 컨트롤러를 설정할 때 애플리케이션 포드를 실행하지 않는 시스템 관련 네임스페이스를 예외 네임스페이스 필드에 넣는 것이 좋습니다. 시스템 관련 네임스페이스를 제외하면 승격된 권한이 필요한 시스템 포드가 차단될 위험을 방지할 수 있습니다. GKE 클러스터의 시스템 관련 네임스페이스에는 다음이 포함될 수 있습니다.
kube-systemkube-publicgke-connectgke-systemconfig-management-systemconfig-management-monitoringgatekeeper-systemistio-systemcnrm-systemknative-servingmonitoring-system
앞의 예외로 정책 컨트롤러를 설정한 후 각 네임스페이스에 admission.gatekeeper.sh/ignore=true 라벨을 추가하여 제약조건 애플리케이션에서 네임스페이스를 제외합니다. 각 네임스페이스에 라벨을 추가하지 않으면 시스템 포드(및 전체 클러스터)가 제한된 정책의 영향을 받을 수 있습니다.
OpenShift SCC를 정책 컨트롤러 제약조건으로 마이그레이션
이 섹션에서는 OpenShift 클러스터에서 SCC를 내보내고 필요한 정책과 일치하도록 대상 GKE Enterprise 정책 컨트롤러 제약조건을 구성하는 방법을 설명합니다. 또한 그에 따라 마이그레이션을 계획할 수 있도록 SCC 및 정책 컨트롤러 제약조건 간의 일부 차이점도 설명합니다.
OpenShift SCC 평가
OpenShift 클러스터에 설치된 SCC의 목록과 구성을 내보내려면 다음 명령어를 사용하면 됩니다.
모든 SCC 목록을 가져옵니다.
oc get scc각 SCC의 구성을 내보냅니다.
oc get scc SCC_NAME > SCC_NAME.yamlSCC_NAME을 구성을 내보낼 SCC의 이름으로 바꿉니다.
구성을 내보낸 후에는 이를 분석하고 다음 OpenShift SCC 매핑 섹션의 테이블을 사용하여 애플리케이션 보안 요구사항과 일치하는 정책 컨트롤러 제약조건을 구성할 수 있습니다.
OpenShift SCC를 정책 컨트롤러 제약조건 템플릿에 매핑
다음 표는 OpenShift SCC 필드와 가능한 값에 해당하는 정책 컨트롤러 제약조건 및 설정을 제공합니다. 이 표를 사용하면 원본 환경에서 OpenShift SCC를 통해 구현된 애플리케이션 보안 요구사항과 일치하는 대상 정책 컨트롤러 제약조건을 구성할 수 있습니다. 이 문서의 뒷부분에 나오는 엔드 투 엔드 마이그레이션 예시 섹션에서 표의 정보를 사용하는 방법의 예시를 제공합니다.
| OpenShift SCC 필드 | 유형/가능한 값 | 정책 컨트롤러 제약조건 템플릿 | 정책 컨트롤러 제약조건 사양 |
|---|---|---|---|
allowPrivilegedContainer: |
불리언 | K8sPSPPrivilegedContainer | 해당하는 경우 권한이 있는 컨테이너를 방지합니다. |
allowHostIPC: |
부울 | K8sPSPHostNamespace | 해당되는 경우 호스트 pid 및 ipc 네임스페이스에 대한 액세스를 방지합니다. |
allowHostPID: |
부울 | K8sPSPHostNamespace | 해당되는 경우 호스트 pid 및 ipc 네임스페이스에 대한 액세스를 방지합니다. |
allowHostNetwork: |
부울 | K8sPSPHostNetworkingPorts | 호스트 네트워크에 대한 액세스를 방지하는 부울 매개변수가 있으며 액세스 가능한 호스트 포트의 범위를 정의할 수 있습니다. |
allowHostPorts: |
부울 | K8sPSPHostNetworkingPorts | 호스트 네트워크에 대한 액세스를 방지하는 부울 매개변수가 있으며 액세스 가능한 호스트 포트의 범위를 정의할 수 있습니다. |
readOnlyRootFilesystem: |
부울 | K8sPSPReadOnlyRootFilesystem | 적용되는 경우 컨테이너 루트 파일 시스템을 읽기 전용으로 마운트할 수 있습니다. |
allowPrivilegeEscalation: true |
부울 | K8sPSPAllowPrivilegeEscalationContainer | AllowPrivilegeEscalation 보안 컨텍스트가 있는 포드가 true로 설정되는 것을 방지합니다. |
allowHostDirVolumePlugin: |
부울 | K8sPSPVolumeTypes | 호스트 디렉터리를 포함하여 허용되는 볼륨 유형(SCC 등) 목록을 정의하는 매개변수가 있습니다. |
volumes: |
허용되는 볼륨 유형이 있는 배열 목록 | K8sPSPVolumeTypes | 호스트 디렉터리를 포함하여 허용되는 볼륨 유형(SCC 등) 목록을 정의하는 매개변수가 있습니다. |
allowedCapabilities: |
요청할 수 있는 Linux 기능의 배열 목록입니다. | K8sPSPCapabilities | 요청할 수 있는 Linux 기능(allowedCapability)과 금지되는 Linux 기능(requiredDropCapabilites)을 정의하는 매개변수가 있습니다.
OpenShift SCC의 |
defaultAddCapabilities: |
각 컨테이너에 추가해야 하는 Linux 기능의 배열 목록입니다. | K8sPSPCapabilities | 요청할 수 있는 Linux 기능(allowedCapability)과 금지되는 Linux 기능(requiredDropCapabilites)을 정의하는 매개변수가 있습니다.
OpenShift SCC의 |
requiredDropCapabilities: |
포드나 컨테이너에서 자동으로 삭제되는 Linux 기능의 배열 목록입니다. | K8sPSPCapabilities | 요청할 수 있는 Linux 기능(allowedCapability)과 금지되는 Linux 기능(requiredDropCapabilites)을 정의하는 매개변수가 있습니다.
OpenShift SCC의 |
fsGroup: |
다음 중 하나일 수 있는 type: key가 있습니다.
|
K8sPSPAllowedUsers | SCC의 type: key와 비슷한 함수와 runAsUser, runAsGroup, supplementalGroups, fsGroup 매개변수의 id 범위가 있는 규칙을 정의할 수 있습니다.
사용자, 그룹, 추가 그룹 또는 FS 그룹의 허용 범위를 정의하는 데 사용할 수 있지만 OpenShift SCC에서처럼 포드에서 직접 사용자 ID를 설정할 수는 없습니다. |
runAsUser: |
다음 중 하나일 수 있는 type: key가 있습니다.
|
K8sPSPAllowedUsers | SCC의 type: key와 비슷한 함수와 runAsUser, runAsGroup, supplementalGroups, fsGroup 매개변수의 id 범위가 있는 규칙을 정의할 수 있습니다.
사용자, 그룹, 추가 그룹 또는 FS 그룹의 허용 범위를 정의하는 데 사용할 수 있지만 OpenShift SCC에서처럼 포드에서 직접 사용자 ID를 설정할 수는 없습니다. |
supplementalGroups: |
다음 중 하나일 수 있는 type: key가 있습니다.
|
K8sPSPAllowedUsers | SCC의 type: key와 비슷한 함수와 runAsUser, runAsGroup, supplementalGroups, fsGroup 매개변수의 id 범위가 있는 규칙을 정의할 수 있습니다.
사용자, 그룹, 추가 그룹 또는 FS 그룹의 허용 범위를 정의하는 데 사용할 수 있지만 OpenShift SCC에서처럼 포드에서 직접 사용자 ID를 설정할 수는 없습니다. |
seLinuxContext: |
다음 중 하나일 수 있는 type: key가 있습니다.
|
K8sPSPSELinuxV2 | 허용되는 수준, 역할, 유형, 사용자 seLinuxOptions를 설정할 수 있는 allowedSELinuxOptions 매개변수가 있습니다. |
OpenShift SCC와 정책 컨트롤러 제약조건의 차이점
이 섹션에서는 정책 컨트롤러 제약조건과 OpenShift SCC 간의 몇 가지 차이점을 설명합니다. 앞의 표를 사용하여 대상 환경에 제약조건을 배포하기 전에 이러한 차이점을 고려합니다.
리소스에 제약조건이 적용되는 방식
SCC 객체에 있는 users: 또는 group: 사양을 사용하여 OpenShift SCC를 사용자와 그룹에 할당할 수 있습니다. OpenShift 4.x 이상 버전에서는 역할 기반 액세스 제어(RBAC)를 사용하여 SCC를 사용자나 그룹에 할당할 수도 있습니다.
SCC에는 포드에 적용되는 SCC를 주문하는 데 사용되는 priority: 필드도 있습니다.
정책 컨트롤러 제약조건은 사용자나 서비스 계정을 타겟팅하는 대신 제약조건의 특정 리소스 선택기를 통해 대상 클러스터, 네임스페이스 또는 포드에 적용됩니다. 자세한 내용은 정책 컨트롤러 문서를 참조하세요. 특정 리소스 선택기를 사용하면 권한이 낮은 사용자가 배포 도구를 사용하여 포드를 실행하거나 클러스터 관리자가 명령줄에서 포드를 시작하는지 여부에 관계없이 포드가 동일하게 동작하도록 할 수 있습니다.
정책 컨트롤러 제약조건은 테스트 실행 모드도 지원하므로 실제로 적용하기 전에 정책을 테스트하고 위반사항을 감사할 수 있습니다. 이 모드를 사용하면 기존 워크로드에 미치는 영향을 방지할 수 있으며 SCC가 사용자에게 적용 가능한 경우 항상 적용됩니다.
OpenShift 네임스페이스에서 사전 할당된 값을 사용하는 SCC 포드 변형
OpenShift SCC에서는 네임스페이스의 주석에서 제공하는 사전 할당된 범위의 특정 ID로 SCC가 적용되는 각 포드의 관련 보안 컨텍스트를 변경할 수 있습니다. MustRunAs 또는 MustRunAsRange 전략 유형으로 RunAsUser, fsGroup, supplementalGroups, seLinuxContext 필드를 사용하면 됩니다.
예를 들어 SCC에 범위가 정의되어 있지 않은 MustRunAsRange 전략 유형이 포함된 RunAsUser 필드가 있는 restricted SCC를 살펴보겠습니다. 이 시나리오에서는 SCC가 적용되는 각 포드가 포드 네임스페이스의 openshift.io/sa.scc.uid-range 주석에서 지정된 범위에서 RunAsUser ID를 가져옵니다.
정책 컨트롤러 제약조건과 변형 기능은 포드 유효성 검사와 변형을 모두 제공합니다. 하지만 제약조건은 네임스페이스의 주석을 사용하여 포드 보안 컨텍스트의 값을 제공하지 않습니다. 다음 섹션인 엔드 투 엔드 마이그레이션 예시에서는 애플리케이션 제공팀이 앞에 나와 있는 제한사항과 비슷한 제한사항을 구현하는 제약조건을 준수하도록 포드에 보안 컨텍스트를 명시적으로 구성해야 하는 방법의 예시를 설명합니다.
엔드 투 엔드 마이그레이션 예시
이 섹션에서는 대상 GKE 클러스터에서 다음 OpenShift 기본 SCC를 매핑하는 데 필요한 모든 정책 컨트롤러 제약조건과 변형자가 포함된 대상 매니페스트 파일 예시를 제공합니다.
privilegedanyuidnonrootrestricted
포드가 실행되는 네임스페이스에 따라 원본 OpenShift 환경에 정의된 SCC 정책을 매핑할 때 포드에서 다른 정책 컨트롤러 제약조건을 가져옵니다.
권한이 있는 모드에서 실행하거나 호스트 리소스에 액세스하는 기능과 같은 가장 높은 액세스 권한이 필요한 워크로드는 정책 컨트롤러 구성에 정의된 예외 네임스페이스 중 하나에서 실행되어야 합니다.
제약조건은 예외 네임스페이스에 적용되지 않습니다. 이 최고 액세스 권한이 있는 워크로드는 일반적으로 시스템 구성요소이거나 권한이 있는 SCC가 소스 OpenShift 환경에 적용된 워크로드입니다.
예외가 아닌 네임스페이스에 생성되는 모든 포드는 가장 제한적인 제약조건을 가져옵니다. 이러한 제약조건은 모든 호스트 기능에 대한 액세스를 거부하며 특정 범위에 속하는 UID를 사용하여 포드를 실행해야 합니다. 이 구성은 OpenShift
restrictedSCC에 적용되는 정책과 일치합니다. 이 구성의 예외는 다음과 같습니다.security=anyuid라벨이 있는 네임스페이스에서 생성된 포드는 이전의 제한적인 제약조건을 가져오지만 모든 UID 및 GID로 실행될 수 있습니다. 이는 OpenShift의anyuidSCC 제약조건과 일치합니다.security=nonroot라벨이 있는 네임스페이스에서 생성된 포드는 이전의 제한적인 제약조건을 가져옵니다. 그러나 포드는 루트가 아닌 UID로 실행될 수 있습니다. 이는 OpenShift의nonrootSCC 제약조건과 일치합니다.
대상 매니페스트 예시
다음은 앞의 엔드 투 엔드 마이그레이션 예시에서 설명한 동작과 일치하는 정책 컨트롤러 제약조건과 변형자의 집합이 포함된 단일 매니페스트 예시입니다. 이 예시에서 제약조건이나 해당 범위를 검토하고 조직 요구사항에 따라 조정하는 것이 좋습니다.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostNamespace
metadata:
name: psp-host-namespace
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostNetworkingPorts
metadata:
name: psp-host-network-ports
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
hostNetwork: false
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
name: psp-privileged-container
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
---
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
name: restricted-capabilities
spec:
applyTo:
- groups: [""]
kinds: ["Pod"]
versions: ["v1"]
match:
scope: Namespaced
kinds:
- apiGroups: ["*"]
kinds: ["Pod"]
namespaceSelector:
matchExpressions:
- operator: NotIn
key: security
values: ["anyuid"]
location: "spec.containers[name:*].securityContext.capabilities.drop"
parameters:
assign:
value: ["KILL","MKNOD","SYS_CHROOT"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
name: restricted-capabilities
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
namespaceSelector:
matchExpressions:
- operator: NotIn
key: security
values: ["anyuid"]
parameters:
requiredDropCapabilities: ["KILL","MKNOD","SYS_CHROOT"]
---
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
name: anyuid-capabilities
spec:
applyTo:
- groups: [""]
kinds: ["Pod"]
versions: ["v1"]
match:
scope: Namespaced
kinds:
- apiGroups: ["*"]
kinds: ["Pod"]
namespaceSelector:
matchExpressions:
- operator: In
key: security
values: ["anyuid"]
location: "spec.containers[name:*].securityContext.capabilities.drop"
parameters:
assign:
value: ["MKNOD"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
name: anyuid-capabilities
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
namespaceSelector:
matchExpressions:
- operator: In
key: security
values: ["anyuid"]
parameters:
requiredDropCapabilities: ["MKNOD"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
name: restricted-users-and-groups
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
namespaceSelector:
matchExpressions:
- operator: NotIn
key: security
values: ["anyuid","nonroot"]
parameters:
runAsUser:
rule: MustRunAs # MustRunAsNonRoot # RunAsAny
ranges:
- min: 1000
max: 2000
fsGroup:
rule: MustRunAs # MayRunAs # RunAsAny
ranges:
- min: 1000
max: 2000
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
name: nonroot-users-and-groups
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
namespaceSelector:
matchExpressions:
- operator: In
key: security
values: ["nonroot"]
parameters:
runAsUser:
rule: MustRunAsNonRoot
fsGroup:
rule: MustRunAsNonRoot
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
name: psp-volume-types
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
volumes:
- configMap
- downwardAPI
- emptyDir
- nfs
- persistentVolumeClaim
- projected
- secret
예시 매니페스트의 restricted-users-and-groups 제약조건은 K8sPSPAllowedUsers 템플릿을 사용하여 runAsUser: 및 fsGroup: 매개변수에 예시 범위 1000~2000을 명시적으로 설정합니다. runAsUser: 및 fsGroup:에 해당 범위의 ID를 사용하도록 설정되지 않은 포드는 차단됩니다.
GKE Enterprise 및 Kubernetes는 네임스페이스 주석을 사용하여 특정 사용자나 그룹 ID가 있는 포드를 자동으로 변형하지 않습니다. 따라서 이전 예시와 같이 UID 범위를 제한하려면 애플리케이션 제공팀이 생성된 포드에서 규정을 준수하는 UID를 명시적으로 설정해야 합니다. 그렇지 않으면 ID를 허용하도록 제약조건을 완전히 삭제해야 합니다.
다음은 만든 모든 네임스페이스의 이전 제약조건을 준수하는 포드 매니페스트의 예시입니다(매니페스트가 restricted SCC를 준수함).
apiVersion: v1
kind: Pod
metadata:
name: restricted-pod-example
spec:
securityContext:
runAsUser: 1000
fsGroup: 1100
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
다음 단계
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기