AWS EKS - Security - Pod Security Standards

CloudNet@ 팀의 AWS EKS Workshop Study 2기 - 6주차
# EKS Workshop 참고

• Kubernetes를 안전하게 도입하려면 클러스터에 대한 원치 않는 변경을 방지해야 합니다. 원치 않는 변경은 클러스터 운영, 워크로드 동작을 방해하고 전체 환경 무결성을 손상시킬 수 있습니다.
• 파드 보안을 제어하기 위해 쿠버네티스는 파드 보안 정책/PSP 리소스를 제공한다. PSP는 클러스터에서 파드가 생성되거나 업데이트되기 전에 충족해야 하는 보안 설정 집합을 지정한다. 그러나 쿠버네티스 버전 1.21부터 PSP는 더 이상 사용되지 않으며, 쿠버네티스 버전 1.25에서 제거될 예정이다.
• 쿠버네티스에서 PSP는 파드 보안 표준(PSS)에 설명된 보안 제어를 구현하는 내장된 어드미션 컨트롤러인 파드 보안 어드미션/PSA로 대체되고 있다. 쿠버네티스 버전 1.23부터 PSA와 PSS는 모두 베타 기능 상태에 도달했으며, Amazon Elastic Kubernetes Service(EKS)에서 기본적으로 활성화되어 있습니다.

Pod Security Standards (PSS) and Pod Security Admission (PSA)

• PSS는 "보안 스펙트럼을 광범위하게 포괄하기 위해 세 가지 정책을 정의합니다. 이러한 정책은 누적적이며 매우 허용적인 것부터 매우 제한적인 것까지 다양합니다."
  
  
• 정책 수준은 다음과 같이 정의됩니다:
  • Privileged
    •  무제한(보안되지 않음) 정책으로, 가능한 가장 광범위한 수준의 권한을 제공합니다. 이 정책은 알려진 권한 상승을 허용합니다. 정책이 없는 상태입니다. 로깅 에이전트, CNI, 스토리지 드라이버 및 권한 액세스가 필요한 기타 시스템 전체 애플리케이션과 같은 애플리케이션에 적합합니다.
  • Baseline
    •  알려진 권한 상승을 방지하는 최소한의 제한적인 정책입니다. 기본(최소로 지정된) 파드 구성을 허용합니다. 기준선 정책은 호스트네트워크, 호스트PID, 호스트IPC, 호스트경로, 호스트포트, 리눅스 기능 추가 불가 및 기타 여러 제한 사항의 사용을 금지한다.
  • Restricted
    • 현재 파드 강화 모범 사례를 따르는 매우 제한적인 정책. 이 정책은 기준선을 상속하며 루트 또는 루트 그룹으로 실행할 수 없는 것과 같은 추가 제한을 추가한다. 제한된 정책은 애플리케이션의 기능에 영향을 미칠 수 있다. 주로 보안이 중요한 애플리케이션을 실행하는 것을 대상으로 합니다.
      
      
• PSA admission controller 는 아래 나열된 세 가지 작동 모드를 통해 PSS 정책에 명시된 제어를 구현합니다.
  • enforce : 정책을 위반하면 파드가 거부된다.
  • audit: 정책 위반은 감사 로그에 기록된 이벤트에 감사 어노테이션을 추가하지만, 그 외에는 허용된다.
  • warn: 정책 위반은 사용자 대상 경고를 트리거하지만, 그 외에는 허용된다.
• 내장된 포드 보안 어드미션 적용
• 쿠버네티스 버전 1.23부터, 파드시큐리티 기능 게이트는 아마존 EKS에서 기본적으로 활성화된다. 업스트림 쿠버네티스 버전 1.23의 기본 PSS 및 PSA 설정은 아래 목록과 같이 Amazon EKS에도 사용됩니다.

파드시큐리티 기능 게이트는 쿠버네티스 v1.23과 v1.24에서 베타 버전(apiVersion: v1beta1)으로 제공되며, 쿠버네티스 v1.25에서 정식 버전(GA, apiVersion: v1)으로 제공된다.

 

 

• 위의 설정은 다음과 같은 클러스터 전체 시나리오를 구성한다:
  
  • 쿠버네티스 API 서버 시작 시 PSA 예외가 구성되지 않음.
  • 모든 PSA 모드에 대해 기본적으로 권한 있는 PSS 프로파일이 구성되고 최신 버전으로 설정됩니다.

Pod Security Admission labels for Namespaces

• 위의 기본 구성이 주어졌을 때, 쿠버네티스 네임스페이스 수준에서 특정 PSS 프로파일과 PSA 모드를 구성하여 PSA와 PSS에서 제공하는 파드 보안에 네임스페이스를 선택해야 한다. 
• 네임스페이스를 구성하여 파드 보안에 사용할 어드미션 제어 모드를 정의할 수 있다. 
• 쿠버네티스 레이블을 사용하면 지정된 네임스페이스의 파드에 사용할 사전 정의된 PSS 레벨 중 어느 것을 선택할 수 있다. 
• 선택한 레이블은 잠재적인 위반이 감지될 경우 PSA가 취하는 조치를 정의한다. 아래에서 볼 수 있듯이, 일부 또는 모든 모드를 구성하거나 모드마다 다른 레벨을 설정할 수도 있다. 각 모드에는 사용되는 정책을 결정하는 두 가지 레이블이 있습니다.

 

• 아래는 테스트에 사용할 수 있는 PSA 및 PSS 네임스페이스 구성의 예입니다. 선택 사항인 PSA 모드 버전 레이블은 포함하지 않았습니다. 기본적으로 구성된 클러스터 전체 설정인 최신을 사용했습니다. 아래에서 원하는 레이블의 주석을 제거하면 각 네임스페이스에 필요한 PSA 모드 및 PSS 프로파일을 활성화할 수 있습니다.

 

Admission Controllers 검증

• 쿠버네티스에서 어드미션 컨트롤러는 요청이 etcd로 지속되기 전에 쿠버네티스 API 서버에 대한 요청을 가로채서 클러스터를 변경하는 데 사용되는 코드 조각입니다. 
• 어드미션 컨트롤러는 변경, 유효성 검사 또는 둘 다 유형일 수 있습니다. PSA의 구현은 유효성 검사 어드미션 컨트롤러이며, 인바운드 파드 명세 요청이 지정된 PSS를 준수하는지 확인한다.
• 아래 흐름에서, 변경 및 유효성 검사 동적 어드미션 컨트롤러(어드미션 웹후크라고도 함)는 웹후크를 통해 쿠버네티스 API 서버 요청 흐름에 통합된다. 이러한 웹후크는 특정 유형의 API 서버 요청에 응답하도록 구성된 서비스를 호출합니다.
• 예를 들어, 웹후크를 사용하여 동적 어드미션 컨트롤러를 구성하여 파드의 컨테이너가 루트가 아닌 사용자로 실행 중인지 또는 컨테이너가 신뢰할 수 있는 레지스트리에서 소싱되었는지 확인할 수 있다.

  

PSA 및 PSS 사용

• PSA는 PSS에 설명된 정책을 시행하고, PSS 정책은 일련의 파드 보안 프로파일을 정의한다. 아래 다이어그램에서는 파드 및 네임스페이스와 함께 PSA와 PSS가 어떻게 함께 작동하여 파드 보안 프로파일을 정의하고 해당 프로파일을 기반으로 어드미션 컨트롤을 적용하는지에 대해 간략하게 설명한다. 아래 다이어그램에서 볼 수 있듯이, PSA 적용 모드와 PSS 정책은 대상 네임스페이스의 레이블로 정의된다.

  

---

✅ 실습준비

---

✅ Privileged PSS profile

• 쿠버네티스 버전 1.23부터 기본적으로 클러스터 수준에서 모든 PSA 모드(즉, 적용, 감사 및 경고)가 특권 PSS 프로파일에 대해 활성화됩니다.
• 기본적으로 PSA는 모든 네임스페이스에서 특권 PSS 프로파일(즉, 제한이 없는)을 가진 디플로이먼트 또는 파드를 허용한다.
• 이러한 기본 설정은 클러스터에 미치는 영향이 적고 애플리케이션에 대한 부정적인 영향을 줄인다.
• 네임스페이스 레이블을 사용하여 보다 제한적인 설정을 선택할 수 있습니다.
  
  
• 기본적으로 자산 네임스페이스에 명시적으로 추가된 PSA 레이블이 없는지 확인할 수 있습니다:

• assets 네임스페이스에는 PSA 레이블이 첨부되어 있지 않습니다.
• 또한 assets 네임스페이스에서 현재 실행 중인 디플로이먼트와 파드가 있는지 확인합니다.
  
  

• assets  파드에 대한 YAML은 현재 보안 구성을 보여줍니다:

• 파드 보안 구성에서, 보안컨텍스트는 파드 수준에서 nil이다. 컨테이너 수준에서, 보안컨텍스트는 모든 리눅스 기능을 삭제하도록 구성되어 있고 readOnlyRootFilesystem은 false로 설정되어 있다. 배포와 파드가 이미 실행 중이라는 사실은 PSA(기본적으로 특권 PSS 프로파일에 대해 구성됨)가 파드 보안 구성 위에 허용되었음을 나타낸다.
  
  
• 하지만 이 PSA가 허용하는 다른 보안 제어는 무엇일까? 
  • 이를 확인하기 위해, 위의 파드 보안 구성에 몇 가지 권한을 더 추가하고 자산 네임스페이스에서 PSA가 여전히 허용하는지 여부를 확인해 보겠습니다. 
  • 구체적으로 파드에 privileged 및 runAsUser:0 플래그를 추가하여 모니터링 에이전트 및 서비스 메시 사이드카와 같이 일반적으로 필요한 워크로드인 호스트 리소스에 액세스할 수 있고 루트 사용자로 실행할 수 있도록 허용해 보겠습니다:
  • ec2-user:~/environment $ cat eks-workshop/modules/security/pss-psa/privileged-workload/deployment.yaml
    
    

• Kustomize 를 실행하여 위의 변경 사항을 적용하고 PSA가 위의 보안 권한으로 파드를 허용하는지 확인합니다.

• 에셋 네임스페이스에서 위의 보안 권한으로 디플로이먼트와 파드가 다시 생성되었는지 확인해 보겠습니다.

• 이는 특권 PSS 프로파일에 대해 활성화된 기본 PSA 모드가 허용적이며 필요한 경우 파드가 상승된 보안 권한을 요청할 수 있음을 보여줍니다.
• 위의 보안 권한은 특권 PSS 프로파일에서 허용되는 제어의 전체 목록이 아니라는 점에 유의합니다.

---

✅ Baseline PSS Profile

• 파드가 요청할 수 있는 권한을 제한하려면 어떻게 해야 할까? 예를 들어, 이전 섹션에서 에셋 파드에 제공한 권한은 공격자가 컨테이너 외부의 호스트 리소스에 액세스할 수 있도록 허용하는 위험한 권한일 수 있다.
• 베이스라인 PSS는 알려진 권한 상승을 방지하는 최소한의 제한 정책이다.
• 이를 활성화하기 위해 에셋 네임스페이스에 레이블을 추가해 보겠습니다:

• Kustomize 을 실행하여 이 변경 사항을 적용하여 에셋 네임스페이스에 레이블을 추가합니다:

• 디플로이먼트 에셋의 파드가 네임스페이스 레이블 pod-security.kubernetes.io/warn에서 제공하는 기준 PSS를 위반한다는 경고가 표시된 것을 볼 수 있습니다.
• 이제 에셋 디플로이먼트의 파드를 재활용합니다.

• 파드가 실행 중인지 확인해 보겠습니다.

 

• 네임스페이스 레이블이 pod-security.kubernetes.io/enforce로 인해 실행 중인 파드가 없지만 그 이유는 즉시 알 수 없습니다.
• PSA 모드를 독립적으로 사용하면 서로 다른 사용자 경험을 초래하는 서로 다른 응답이 있습니다.
•  enforce mode 는 각 파드 사양이 구성된 PSS 프로파일을 위반하는 경우 파드를 생성하지 못하게 합니다.
• 그러나 이 모드에서는 디플로이먼트와 같이 파드를 생성하는 파드 이외의 쿠버네티스 오브젝트는 그 안에 있는 파드 스펙이 적용된 PSS 프로파일을 위반하더라도 클러스터에 적용되는 것을 방지하지 않습니다. 이 경우 파드가 적용되지 않는 동안 디플로이먼트는 적용됩니다.
  
  
• 명령어를 실행하여 디플로이먼트 리소스를 검사하여 상태 조건을 확인합니다.

 

• 일부 시나리오에서는 성공적으로 적용된 디플로이먼트 오브젝트가 실패한 파드 생성을 반영한다는 즉각적인 표시가 없습니다.
• 문제가 있는 파드 사양은 파드를 생성하지 않는다. 위의 테스트에서 보았던 것처럼 kubectl get deploy -o yaml ...로 디플로이먼트 리소스를 검사하면 실패한 파드(들) .status.conditions 요소의 메시지가 노출됩니다.
• 감사 및 경고 PSA 모드 모두에서, 파드 제한은 위반 파드가 생성 및 시작되는 것을 막지 않습니다.
• 그러나 이러한 모드에서는 API 서버 감사 로그 이벤트에 대한 감사 어노테이션과 API 서버 클라이언트(예: kubectl)에 대한 경고가 각각 트리거된됩니다.
• 이는 파드와 파드를 생성하는 오브젝트에 PSS 위반이 있는 파드 스펙이 포함되어 있을 때 발생한다.
  
  
• privileged flag를 제거하여 실행되도록 에셋 배포를 수정해 보겠습니다:
  
  

• 이번에는 경고를 받지 않았으므로 파드가 실행 중인지 확인하면 더 이상 루트 사용자로 실행되고 있지 않은지 확인할 수 있습니다:

• privileged mode 에서 실행 중인 파드를 수정했기 때문에 이제 Baseline profile 에서 실행할 수 있습니다.

---

✅ Restricted PSS Profile

• 가장 엄격하게 제한되는 정책인 Restricted profile 을 확인합니다.
• 에셋 네임스페이스에 레이블을 추가하여 Restricted PSS profile 에 대해 모든 PSA 모드를 활성화합니다:

• Kustomize  을 실행하여 이 변경 사항을 적용하여 에셋 네임스페이스에 레이블을 추가합니다:
• Baseline profile 과 마찬가지로 에셋 배포가 제한 프로필을 위반하고 있다는 경고가 표시됩니다.

• 파드는 다시 생성되지 않습니다:

 

• 위의 출력은 파드 보안 구성이 제한된 PSS 프로파일을 위반하기 때문에 PSA가 에셋 네임스페이스에서 파드 생성을 허용하지 않았음을 나타낸다. 이 동작은 이전 섹션의 앞부분에서 보았던 것과 동일합니다.
• Restricted profile 의 경우 실제로 프로파일을 충족하기 위해 일부 보안 구성을 사전에 잠가야 합니다.
• 에셋 네임스페이스에 대해 구성된 Privileged PSS profile 을 준수하도록 파드 구성에 몇 가지 보안 컨트롤을 추가해 보겠습니다:

• Kustomize를 실행하여 이러한 변경 사항을 적용하고 배포를 다시 만듭니다:

• PSA가 에셋 네임스페이스에서 위의 변경 사항으로 배포 및 파드를 생성할 수 있는지 확인합니다:

 

• 위의 출력은 파드 보안 구성이 Restricted PSS profile. 로 확인되었으므로 PSA가 허용되었음을 나타낸다.
• 위의 보안 권한은 제한된 PSS 프로파일에서 허용되는 컨트롤의 전체 목록이 아닙니다.