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

5.9. Pod 보안 승인 준수

Pod 보안 승인은 Kubernetes Pod 보안 표준을 구현한 것입니다. Pod 보안 승인은 Pod의 동작을 제한합니다. 전역적으로 정의되거나 네임스페이스 수준에서 정의되지 않은 Pod 보안 승인은 클러스터에 허용되지 않으며 실행할 수 없습니다.

Operator 프로젝트에서 실행하기 위해 에스컬레이션된 권한이 필요하지 않은 경우 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 워크로드를 실행할 수 있습니다. Operator 프로젝트에 에스컬레이션된 권한을 실행해야 하는 경우 다음 보안 컨텍스트 구성을 설정해야 합니다.

  • Operator의 네임스페이스에 허용되는 Pod 보안 승인 수준입니다.
  • 워크로드의 서비스 계정에 허용되는 SCC(보안 컨텍스트 제약 조건)

자세한 내용은 Pod 보안 승인 이해 및 관리를 참조하십시오.

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

5.9.1. Pod 보안 승인 정보

OpenShift Container Platform에는 Kubernetes Pod 보안 승인이 포함됩니다. 전역적으로 정의되거나 네임스페이스 수준에서 정의되지 않은 Pod 보안 승인은 클러스터에 허용되지 않으며 실행할 수 없습니다.

전역적으로 privileged 있는 프로필이 적용되며, restricted 프로필은 경고 및 감사에 사용됩니다.

네임스페이스 수준에서 Pod 보안 승인 설정을 구성할 수도 있습니다.

중요

기본 프로젝트에서 워크로드를 실행하거나 기본 프로젝트에 대한 액세스를 공유하지 마세요. 기본 프로젝트는 핵심 클러스터 구성 요소를 실행하기 위해 예약되어 있습니다.

다음 기본 프로젝트는 높은 권한이 있는 것으로 간주됩니다. default, kube-public, kube-system, openshift, openshift-infra, openshift-node 및 openshift.io/run-level 레이블이 0 또는 1 로 설정된 기타 시스템 생성 프로젝트입니다. Pod 보안 승인, 보안 컨텍스트 제약 조건, 클러스터 리소스 할당량 및 이미지 참조 확인과 같은 승인 플러그인에 의존하는 기능은 높은 권한 있는 프로젝트에서 작동하지 않습니다.

5.9.1.1. Pod 보안 승인 모드

네임스페이스에 대해 다음 Pod 보안 승인 모드를 구성할 수 있습니다.

표 5.18. Pod 보안 승인 모드
모드레이블설명

enforce

pod-security.kubernetes.io/enforce

설정된 프로필을 준수하지 않는 경우 허용에서 Pod를 거부합니다.

audit

pod-security.kubernetes.io/audit

Pod가 설정된 프로필을 준수하지 않는 경우 감사 이벤트 로그

warn

pod-security.kubernetes.io/warn

Pod가 설정된 프로필을 준수하지 않는 경우 경고 표시

5.9.1.2. Pod 보안 승인 프로필

각 Pod 보안 승인 모드를 다음 프로필 중 하나로 설정할 수 있습니다.

표 5.19. Pod 보안 승인 프로필
프로필설명

privileged

최소 제한 정책; 알려진 권한 에스컬레이션 허용

baseline

최소한의 제한 정책; 알려진 권한 에스컬레이션을 방지

restricted

가장 제한적인 정책; 현재 Pod 강화 모범 사례를 따릅니다.

5.9.1.3. 권한이 있는 네임스페이스

다음 시스템 네임스페이스는 항상 privileged 있는 Pod 보안 승인 프로필로 설정됩니다.

  • default
  • kube-public
  • kube-system

이러한 권한 있는 네임스페이스의 Pod 보안 프로필을 변경할 수 없습니다.

5.9.2. Pod 보안 승인 동기화 정보

글로벌 Pod 보안 승인 제어 구성 외에도 컨트롤러는 지정된 네임스페이스에 있는 서비스 계정의 SCC 권한에 따라 Pod 보안 승인 제어 warn 및 audit 레이블을 네임스페이스에 적용합니다.

컨트롤러는 각 네임스페이스에서 보안 컨텍스트 제약 조건을 사용하도록 ServiceAccount 오브젝트 권한을 검사합니다. SCC(보안 컨텍스트 제약 조건)는 필드 값을 기반으로 Pod 보안 프로필에 매핑됩니다. 컨트롤러는 이러한 변환된 프로필을 사용합니다. Pod가 생성될 때 경고 및 로깅 감사 이벤트를 표시하지 않도록 Pod 보안 승인 warn 및 audit 레이블은 네임스페이스에서 가장 권한이 있는 Pod 보안 프로필로 설정됩니다.

네임스페이스 레이블 지정은 네임스페이스 로컬 서비스 계정 권한을 기반으로 합니다.

Pod를 직접 적용하면 Pod를 실행하는 사용자의 SCC 권한을 사용할 수 있습니다. 그러나 사용자 권한은 자동 레이블 지정 중에 고려되지 않습니다.

5.9.2.1. Pod 보안 승인 동기화 네임스페이스 제외

Pod 보안 승인 동기화는 대부분의 시스템에서 생성된 네임스페이스에서 영구적으로 비활성화됩니다. 사용자가 생성한 openshift-* 접두사가 지정된 네임스페이스에서 동기화도 처음에 비활성화되지만 나중에 동기화를 활성화할 수 있습니다.

중요

Pod 보안 승인 레이블(pod-security.kubernetes.io/<mode> )이 레이블 동기화 네임스페이스의 자동 레이블 값에서 수동으로 수정되는 경우 해당 라벨에 대해 동기화가 비활성화됩니다.

필요한 경우 다음 방법 중 하나를 사용하여 동기화를 다시 활성화할 수 있습니다.

  • 네임스페이스에서 수정된 Pod 보안 승인 레이블 제거

  • security.openshift.io/scc.podSecurityLabelSync 라벨을 true로 설정

    이 레이블을 추가하여 동기화를 강제 적용하면 수정된 Pod 보안 승인 라벨을 덮어씁니다.

영구적으로 비활성화된 네임스페이스

클러스터 페이로드의 일부로 정의된 네임스페이스에는 Pod 보안 승인 동기화가 영구적으로 비활성화됩니다. 다음 네임스페이스는 영구적으로 비활성화되어 있습니다.

  • default
  • kube-node-lease
  • kube-system
  • kube-public
  • openshift
  • openshift-operators를 제외하고 openshift- 접두사가 붙은 모든 system-created 네임스페이스
처음에 비활성화된 네임스페이스

기본적으로 openshift- 접두사가 있는 모든 네임스페이스에는 처음에 Pod 보안 승인 동기화가 비활성화되어 있습니다. 사용자가 생성한 openshift-* 네임스페이스 및 openshift-operators 네임스페이스에 대한 동기화를 활성화할 수 있습니다.

참고

openshift-operators 를 제외하고 시스템에서 생성한 openshift-* 네임스페이스에 대해 동기화를 활성화할 수 없습니다.

Operator가 사용자가 생성한 openshift-* 네임스페이스에 설치하는 경우 네임스페이스에 CSV(클러스터 서비스 버전)가 생성된 후 동기화가 자동으로 활성화됩니다. 동기화된 레이블은 네임스페이스의 서비스 계정 권한에서 파생됩니다.

5.9.3. 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 Operator 워크로드가 실행되도록 합니다.

Operator 프로젝트를 다양한 배포 및 환경에서 실행할 수 있도록 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 실행되도록 Operator의 워크로드를 구성합니다.

주의

runAsUser 필드를 비워 두어야 합니다. 이미지에 특정 사용자가 필요한 경우 제한된 SCC(보안 컨텍스트 제약 조건) 및 제한된 Pod 보안 적용에서 실행할 수 없습니다.

프로세스

  • 제한된 Pod 보안 수준으로 설정된 네임스페이스에서 실행되도록 Operator 워크로드를 구성하려면 다음 예와 유사한 Operator의 네임스페이스 정의를 편집합니다.

    중요

    Operator의 네임스페이스 정의에 seccomp 프로필을 설정하는 것이 좋습니다. 그러나 OpenShift Container Platform 4.10에서는 seccomp 프로필 설정이 지원되지 않습니다.

    • OpenShift Container Platform 4.11 이상에서만 실행해야 하는 Operator 프로젝트의 경우 다음 예와 유사한 Operator의 네임스페이스 정의를 편집합니다.

      config/manager/manager.yaml 파일 예

      ...
spec:
 securityContext:
   seccompProfile:
     type: RuntimeDefault 1
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...

      1
      seccomp 프로필 유형을 RuntimeDefault 로 설정하면 SCC의 기본값은 네임스페이스의 Pod 보안 프로파일입니다.

    • OpenShift Container Platform 4.10에서도 실행해야 하는 Operator 프로젝트의 경우 다음 예와 유사한 Operator의 네임스페이스 정의를 편집합니다.

      config/manager/manager.yaml 파일 예

      ...
spec:
 securityContext: 1
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...

      1
      seccomp 프로필 유형을 설정하지 않으면 Operator 프로젝트를 OpenShift Container Platform 4.10에서 실행할 수 있습니다.

추가 리소스

5.9.4. 에스컬레이션된 권한이 필요한 Operator 워크로드에 대한 Pod 보안 승인 관리

Operator 프로젝트에 에스컬레이션된 권한을 실행해야 하는 경우 Operator의 CSV(클러스터 서비스 버전)를 편집해야 합니다.

프로세스

  1. 다음 예와 유사하게 보안 컨텍스트 구성을 Operator CSV의 필수 권한 수준으로 설정합니다.

    네트워크 관리자 권한이 있는 < operator_name>.clusterserviceversion.yaml 파일의 예

    ...
containers:
   - name: my-container
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         add:
           - "NET_ADMIN"
...

  2. Operator의 워크로드가 다음 예와 유사하게 필요한 SCC(보안 컨텍스트 제약 조건)를 사용할 수 있는 서비스 계정 권한을 설정합니다.

    Example <operator_name>.clusterserviceversion.yaml file

    ...
  install:
    spec:
      clusterPermissions:
      - rules:
        - apiGroups:
          - security.openshift.io
          resourceNames:
          - privileged
          resources:
          - securitycontextconstraints
          verbs:
          - use
        serviceAccountName: default
...

  3. Operator의 CSV 설명을 편집하여 다음 예와 유사한 Operator 프로젝트에 에스컬레이션된 권한이 필요한 이유를 설명합니다.

    Example <operator_name>.clusterserviceversion.yaml file

    ...
spec:
  apiservicedefinitions:{}
  ...
description: The <operator_name> requires a privileged pod security admission label set on the Operator's namespace. The Operator's agents require escalated permissions to restart the node if the node needs remediation.

5.9.5. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.