팟 (Pod) 보안 승인

Pod 보안 인증은 Pod의 동작을 제한하는 ‘ Kubernetes ’ Pod 보안 표준을 구현하며, 관련 네임스페이스에 대해 구성된 Pod 보안 프로필 정책을 위반하는 Pod에 대해 경고 메시지와 kube-apiserver 감사 이벤트를 제공합니다.

IBM Cloud Kubernetes Service 버전 1.25 이상에는 Kubernetes 팟 (Pod) 보안 허가에 대한 지원이 포함되어 있습니다. 자세한 정보는 Kubernetes 문서의 팟(Pod)보안 허가팟(Pod)보안 표준 을 참조하십시오.

IBM Cloud Kubernetes Service 버전 1.25 및 이후 버전에서는 Pod Security Admission이 항상 활성화되어 있습니다. Kubernetes 의 이전 버전에서는 Pod 보안 정책을 사용합니다.

보안 프로파일 이해

Kubernetes 의 파드 보안 표준은 다음 세 가지 프로필을 정의합니다.

권한이 부여됨
기본 팟 (Pod) 보안 구성은 privileged Kubernetes 팟 (Pod) 보안 프로파일을 글로벌로 적용합니다. 이 프로파일은 제한되지 않으며 알려진 권한 에스컬레이션을 허용하고 restricted 프로파일에서 설정한 정책을 기반으로 경고 및 감사 이벤트를 생성합니다.
기준선
baseline 프로파일은 알려진 권한 에스컬레이션을 방지하는 제한적인 프로파일입니다. 기본 (최소로 지정된) 팟 (Pod) 구성을 허용합니다.
제한됨
restricted 프로파일은 엄격히 제한되며 현재 팟 (Pod) 강화 우수 사례를 따릅니다.

팟 (Pod) 보안 프로파일에 대한 자세한 정보는 Kubernetes 문서의 프로파일 세부사항 을 참조하십시오.

팟 (Pod) 보안 허가에는 잠재적 위반이 발견되는 경우 제어 플레인이 수행하는 조치를 정의하는 세 가지 모드가 포함되어 있습니다.

적용
정책 위반으로 인해 팟 (Pod) 이 거부됩니다.
감사
정책 위반은 감사 로그에 기록된 이벤트에 감사 어노테이션을 추가하도록 트리거하지만, 그렇지 않으면 허용됩니다.
경고
정책 위반은 사용자가 직면하는 경고를 트리거하지만 그렇지 않으면 허용됩니다.

새 기능을 처리하기 위해 보안 표준 또는 프로파일 구현이 변경되면 특정 버전의 역할을 사용하도록 팟 (Pod) 보안 허가를 구성할 수 있습니다. 다음 버전이 지원됩니다.

  • Kubernetes major.minor 버전 (예: v1.25)
  • latest

팟 (Pod) 보안 허가가 내게 적합한 선택이 아닌 경우에는 어떻게 해야 합니까?

팟 (Pod) 보안 승인은 항상 사용으로 설정되어 있지만 여러 승인 제어기 중 하나일 수 있습니다. 사용자의 유스 케이스에 적합한 다른 보안 정책 모델을 구현하도록 써드파티 Kubernetes 허가 제어기를 구성할 수 있습니다.

privileged 프로파일을 사용하여 적용, 경고 및 감사하도록 팟 (Pod) 보안 허가를 구성하는 경우 제어 플레인은 모든 팟 (Pod) 이 실행되도록 허용합니다. 그런 다음 다른 허가 제어기가 이를 거부하도록 구성할 수 있습니다.

다음 조치 중 하나를 수행하지 않는 한 써드파티 허가 제어기를 설치할 수 있습니다.

  • 자체 팟 (Pod) 보안 정책 (PSP) 을 설치하지 않습니다.
  • 정책의 일부를 적용하기 위해 SP에 의존하지 않습니다.

팟 (Pod) 보안 허가 네임스페이스 레이블 구성

각 네임스페이스에서 팟 (Pod) 보안에 사용할 허가 제어 모드를 정의할 수 있습니다. Kubernetes 는 네임스페이스에 사용할 사전 정의된 팟 (Pod) 보안 표준 프로파일을 정의하기 위해 설정할 수 있는 레이블 세트를 정의합니다. 선택하는 레이블은 잠재적 위반이 발견되는 경우 제어 플레인이 수행하는 조치를 정의합니다.

기본적으로 IBM Cloud Kubernetes Service 은 privileged 팟 (Pod) 보안 레이블을 다음 네임스페이스에 추가합니다. 이러한 네임스페이스는 privileged 프로파일을 사용하여 enforce, auditwarn 로 레이블 지정됩니다.

  • kube-system
  • ibm-system
  • ibm-operators
  • calico-system (버전 1.29 이상)
  • tigera-operator (버전 1.29 이상)
  • calico-apiserver (버전 1.31 )

이러한 네임스페이스의 레이블을 제거하거나 변경하지 마십시오.

네임스페이스는 임의의 또는 모든 팟 (Pod) 보안 허가 modes 에 대한 팟 (Pod) 보안 프로파일을 설정하기 위해 레이블이 지정될 수 있습니다.

예를 들어, baseline 프로파일을 사용하여 warn 또는 audit 를 사용하는 것 외에 privileged 프로파일을 적용하도록 네임스페이스에 레이블을 지정할 수 있습니다.

이 레이블을 사용하면 관리자 및 애플리케이션 개발자가 팟 (Pod) 을 거부하지 않고 baseline 프로파일에 대해 경고 및 감사 레코드만 검색하여 애플리케이션을 건조 실행할 수 있습니다. 그런 다음 적용 모드를 baseline 로 변경하기 전에 워크로드에 필요한 변경사항을 작성할 수 있습니다.

팟 (Pod) 보안 허가 네임스페이스 레이블의 양식은 pod-security.kubernetes.io/<MODE>: <LEVEL>pod-security.kubernetes.io/<MODE>-version: <VERSION> 입니다.

  • pod-security.kubernetes.io/enforce
  • pod-security.kubernetes.io/enforce-version
  • pod-security.kubernetes.io/audit
  • pod-security.kubernetes.io/audit-version
  • pod-security.kubernetes.io/warn
  • pod-security.kubernetes.io/warn-version

privileged 프로파일을 적용하고 baseline 프로파일 위반에 대한 경고 및 감사 이벤트를 생성하기 위해 네임스페이스에 레이블을 지정하려면 다음 레이블을 사용하십시오.

  • pod-security.kubernetes.io/enforce: privileged
  • pod-security.kubernetes.io/enforce-version: latest
  • pod-security.kubernetes.io/audit: baseline
  • pod-security.kubernetes.io/audit-version: latest
  • pod-security.kubernetes.io/warn: baseline
  • pod-security.kubernetes.io/warn-version: latest

기본 Pod Security Admission 플러그인 구성

IBM Cloud Kubernetes Service 은 기본적으로 다음 PodSecurityConfiguration 를 사용합니다.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

팟 (Pod) 보안 허가 플러그인 구성 사용자 정의

클러스터 전체 팟 (Pod) 보안 허가 플러그인 구성은 팟 (Pod) 보안 레이블 또는 면제가 없는 모든 네임스페이스에 대해 enforce, auditwarn 동작을 설정합니다.

Kubernetes 1.24 클러스터의 경우, apiVersionpod-security.admission.config.k8s.io/v1beta 여야 합니다. 1.25 이상에서는 pod-security.admission.config.k8s.io/v1 을 사용하는 것이 권장되지만, v1beta API 버전도 여전히 사용할 수 있습니다.

  1. PodSecurityConfiguration 자원을 포함하는 YAML 파일을 작성하십시오. 기본 구성을 사용하여 시작할 수 있습니다.

    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "privileged"
      enforce-version: "latest"
      audit: "privileged"
      audit-version: "latest"
      warn: "privileged"
      warn-version: "latest"
    exemptions:
      usernames: []
      runtimeClasses: []
      namespaces: []
    
  2. 사용할 사용자 정의를 작성하십시오. 구성의 각 섹션에 대한 다음 정보를 검토하십시오.

defaults

구성의 defaults 섹션은 팟 (Pod) 보안 레이블이 없는 네임스페이스에 대한 클러스터 전체 기본값을 정의합니다. 필드는 해당 네임스페이스 레이블과 동일한 값을 가질 수 있습니다.

exemptions

구성의 exemptions 섹션을 사용하면 특정 네임스페이스와 연관된 정책으로 인해 달리 금지되는 팟 (Pod) 을 작성할 수 있습니다. 면제 차원에는 다음과 같은 경우가 포함됩니다.

  - 사용자 이름: 면제 인증 (또는 위장) 사용자 이름이 있는 사용자의 요청은 무시됩니다. 사용자 이름은 일반적으로 IAM 사용자 또는 서비스 계정입니다. 예를 들어, `usernames: [ "IAM#user@example.com" ]` 입니다. `admin kubeconfig` 클라이언트 인증서와 연관된 사용자 이름을 면제할 수도 있습니다. `admin kubeconfig` 인증서를 지정하려는 경우 사용자 이름은 현재 클라이언트 인증서의 `CN` 컴포넌트입니다.

      ```sh {: pre}
      kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
      /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
      ```
      다음 예제에서 사용자 이름은 `IBMid-27000xxxxx-admin-2023-05-12` 입니다. 새 `admin kubeconfig` 를 가져오는 경우 사용자 이름이 다를 수 있습니다.

      ```sh {: pre}
      openssl x509 -in <client-certificate> -subject -noout`
      subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
      ```
  - RuntimeClassNames: 면제 런타임 클래스명을 지정하는 파드 및 워크로드 리소스는 무시된다.
  - 네임스페이스: 면제 네임스페이스의 팟 (Pod) 및 워크로드 자원이 무시됩니다.
  1. 사용자 정의 YAML 파일을 저장하십시오.

  2. ibmcloud ks cluster master pod-security set 명령을 실행하십시오.

    ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE
    

ibmcloud ks cluster master pod-security set 명령을 실행할 때 구성 파일을 지정하지 않으면 팟 (Pod) 보안 승인이 기본 구성으로 재설정됩니다.