Ssoon

[6주차] EKS Security - Pod Security Standards 본문

AWS EKS Workshop Study

[6주차] EKS Security - Pod Security Standards

구구달스 2023. 6. 2. 06:07
CloudNet@ 팀의 AWS EKS Workshop Study 6주차 정리입니다.
#EKS Immersion Workshop 의 내용입니다.

Pod 보안을 제어하기 위해 쿠버네티스는 (버전 1.23부터) Pod Security Standards(PSS)에 설명된 보안 제어를 구현하는 기본 제공 어드미션 컨트롤러인 Pod Security Admission (PSA)을 제공하며, 기본적으로 Amazon Elastic Kubernetes Service(EKS)에서 활성화되어 있습니다.

 

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

  • PSA는 PSS에 설명된 정책을 적용하고, PSS 정책은 일련의 파드 보안 프로파일을 정의합니다. 
  • 대상 네임스페이스에서 PSA 적용 모드와 PSS 정책에 대한 레이블을 정의합니다.

 

Pod Security Standards (PSS):

Kubernetes 클러스터에서 실행되는 Pod의 보안 설정을 정의하는 규칙 집합입니다. 이는 클러스터 안에서 실행되는 모든 Pod에 대해 일관된 보안 수준을 유지하고 일반적인 보안 문제를 방지하기 위해 사용됩니다. PSS는 Kubernetes 클러스터 관리자가 정책을 구성하고 강제할 수 있으며, Pod의 보안 구성을 검사하여 규칙을 준수하지 않는 Pod를 거부할 수 있습니다.


Pod Security Admission (PSA):

Kubernetes 클러스터에 대한 사전 보안 검사를 수행하는 기능입니다. PSA는 클러스터 내에서 Pod가 생성되기 전에 Pod의 보안 설정을 평가하고, 정의된 보안 정책을 준수하는지 확인합니다. PSA는 Pod 생성 요청을 받을 때 실행되며, Pod의 보안 구성을 검사하여 클러스터 정책을 위반하는 경우 Pod 생성을 거부하거나 보안 구성을 수정할 수 있는 조치를 취할 수 있습니다.

 

 

PSS는 정책 설정과 강제를 위한 규칙 집합이며, PSA는 Pod 생성 전에 보안 검사를 수행하여 정책 준수를 보장하는 기능입니다. PSS는 정책을 구성하고 PSA는 정책을 평가하고 적용하는 역할을 합니다.

 

  • Privileged: Unrestricted (unsecure) 정책으로, 가능한 가장 광범위한 수준의 권한을 제공합니다. 이 정책은 알려진 privilege escalations 을 허용합니다. 정책이 없는 상태입니다. 로깅 에이전트, CNI, 스토리지 드라이버 및 권한 액세스가 필요한 기타 시스템 전체 애플리케이션과 같은 애플리케이션에 적합합니다.
  • Baseline: 알려진 privilege escalations 을 방지하는 최소한의 제한 정책입니다. 기본(최소로 지정된) POD 구성을 허용합니다. 호스트네트워크, 호스트PID, 호스트IPC, 호스트경로, 호스트포트, 리눅스 기능 추가 불가 및 기타 여러 제한 사항의 사용을 금지합니다.
  • Restricted: 현재 파드 강화 모범 사례를 따르는 Heavily restricted policy. 이 정책은 Baseline을 상속하며 루트 또는 루트 그룹으로 실행할 수 없음과 같은 추가 제한을 추가한다. Restricted 정책은 애플리케이션의 기능에 영향을 미칠 수 있다. 주로 보안이 중요한 애플리케이션을 실행하는 것을 대상으로 합니다.

 

The PSA admission controller 세 가지 작동 모드를 통해 PSS 정책에 명시된 제어를 구현합니다.

  • enforce: 정책을 위반하면 Pod 가 거부
  • audit: 정책 위반은 audit log 에 기록된 이벤트에 audit annotation 추가를 트리거하지만, 그 외에는 허용
  • warn: 정책 위반은 사용자 대상 경고를 트리거하지만, 그 외에는 허용

Privileged Pod Security Standard

Configuring Privileged Profile

cd eks-app-mesh-polyglot-demo
helm upgrade -f workshop/helm-chart/security/values-psa-pss.yaml workshop workshop/helm-chart/
kubectl -n workshop rollout restart deploy frontend 
kubectl -n workshop rollout status deploy frontend
  • 가장 허용 범위가 넓고 알려진 권한 에스컬레이션을 허용하는 Privileged profile PSS

  • workshop 네임스페이스에는 PSA 레이블이 첨부되어 있지 않습니다.
kubectl -n workshop get deployment frontend -o yaml | yq eval '.spec.template.spec' -

  • 파드 수준에서 보안컨텍스트는 null {}이다.
  • 컨테이너 수준에서는 허용되지 않도록 설정하고 runAsUser: 1000으로 설정한다.
  • Pod를 실행 중인 사용자 이름을 확인합니다.
kubectl -n workshop exec -ti $(kubectl get pods -n workshop -l app=frontend -o name) -- whoami

  • 컨테이너 수준에서 위의 파드 보안 구성에 몇 가지 특권 권한을 추가하고, 기본 구성된 PSA가 이를 허용하는지 확인합니다.
  • 구체적으로, 파드에 특권 플래그를 true로 추가하고 runAsUser: 0을 추가하여 호스트 리소스에 접근할 수 있고 루트 사용자로 실행할 수 있음을 의미합니다.
  • 변경 사항을 적용하고 PSA가 위의 보안 권한으로 파드를 허용하는지 확인한다.

kubectl -n workshop get pods -l app=frontend

파드가 실행 중이고 경고가 표시되지 않았다는 것은 특권 PSS 프로파일에 대해 활성화된 기본 PSA 모드가 허용적이며 필요한 경우 파드가 상승된 보안 권한을 요청할 수 있다는 것을 보여준다.

컨테이너 보안컨텍스트 구성과 특권 사용자(루트)로 실행되는지 확인한다.

kubectl -n workshop exec -ti $(kubectl get pods -n workshop -l app=frontend -o name) -- whoami

 

 


Baseline Pod Security Standard

Configuring Baseline Profile

  • 파드가 요청할 수 있는 권한을 제한하고 싶다면 어떻게 해야 할까요?
  • 이전 섹션에서 프론트엔드 파드에 제공한 권한은 공격자가 컨테이너 외부의 호스트 리소스에 액세스할 수 있도록 허용하는 위험한 권한일 수 있습니다.
  • Baseline PSS는 알려진 권한 에스컬레이션을 방지하는 최소한의 제한 정책입니다.
  • 이를 활성화하기 위해 워크샵 네임스페이스에 레이블을 추가합니다.
helm upgrade --reuse-values -f workshop/helm-chart/security/values-psa-pss-baseline-ns.yaml workshop workshop/helm-chart/

W0603 05:53:08.893145   19414 warnings.go:70] existing pods in namespace "workshop" violate the new PodSecurity enforce level "baseline:latest"
W0603 05:53:08.893167   19414 warnings.go:70] frontend-749fd69c6f-trnnw: privileged

  • workshop Namespace 에 baseline PSS가 적용되었는지 확인합니다.

위에서 이미 workshop Namespac 의 Pod 가 Baseline PSS 를 위반한다는 경고를 받은 것을 볼 수 있으며, 이는 네임스페이스 레이블 pod-security.kubernetes.io/warn으로 제공됩니다.

No resources found in workshop namespace. 이는 각 Pod 스펙이 구성된 PSS 프로파일을 위반하는 경우 파드를 생성하지 못하도록 하는 네임스페이스 레이블 pod-security.kubernetes.io/enforce로 인해 발생한다.
그러나 디플로이먼트와 같이 파드를 생성하는 파드 이외의 쿠버네티스 오브젝트는 그 안에 있는 파드 스펙이 적용된 PSS 프로파일을 위반하더라도 클러스터에 적용되지 않도록 방지되지 않는다. 이 경우 파드가 적용되지 않는 동안 디플로이먼트는 적용된다.

  • Deployment 리소스를 검사하여 상태 조건을 찾습니다

  • frontend Deployment를 수정하여 privileged 및 runAsUser:0 플래그를 제거하여 실행합니다.
helm upgrade --reuse-values -f workshop/helm-chart/security/values-psa-pss-baseline.yaml workshop workshop/helm-chart/

  • 경고를 받지 않았으므로 Pod가 실행 중인지 확인합니다.

  • securityContext 컨텍스트 구성의 유효성을 검사하고 NON-privileged 사용자로 실행합니다.

 


Restricted Pod Security Standard

Configuring Restricted Profile

  • 가장 강력하게 제한되는 정책인 Restricted profile
  • workshop Namespace 에 레이블을 추가하여 제한된 PSS 프로파일에 대해 모든 PSA 모드를 활성화합니다.
  • Baseline profile 과 마찬가지로 프론트엔드 배포가 Restricted profile 을 위반하고 있다는 경고를 받고 있습니다.

W0603 06:20:43.286710   20343 warnings.go:70] existing pods in namespace "workshop" violate the new PodSecurity enforce level "restricted:latest"
W0603 06:20:43.286734   20343 warnings.go:70] frontend-7cc88b5c8f-b8k64: unrestricted capabilities, runAsNonRoot != true, seccompProfile
W0603 06:20:43.286740   20343 warnings.go:70] prodcatalog-6f66c677f7-5kjqv (and 1 other pod): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile


"unrestricted capabilities": 컨테이너가 "제한 없는 권한"을 가지고 있다는 것을 나타냅니다. 컨테이너가 특정 작업을 수행하기 위해 필요한 모든 시스템 권한을 가지고 있다는 의미입니다. 이는 보안 측면에서 주의해야 할 부분이며, 컨테이너에 대한 권한 제한을 고려해야 합니다.
"runAsNonRoot != true": 컨테이너가 루트 계정으로 실행되지 않는다는 것을 나타냅니다. 일반적으로 컨테이너를 실행할 때는 루트 계정 대신 보다 제한된 권한을 사용하는 것이 좋습니다. 이는 시스템 보안을 강화하고 잠재적인 취약점을 제한하는 데 도움이 됩니다. 따라서, "runAsNonRoot"가 "true"가 아닌 경우에는 보안 상의 이슈가 될 수 있습니다.
"seccompProfile": 컨테이너의 시스템 콜(Syscall) 프로필을 지정하는 부분입니다. 시스템 콜은 컨테이너가 호스트 운영 체제의 리소스와 상호 작용할 수 있는 방법입니다. "seccompProfile"은 시스템 콜을 제한하고 컨테이너의 보안을 강화하기 위해 사용될 수 있는 프로파일을 지정하는 데 사용됩니다.
"allowPrivilegeEscalation != false": 컨테이너가 권한 상승을 허용하고 있는지를 나타냅니다. 권한 상승은 컨테이너의 권한을 더 높은 수준으로 끌어올려 악용될 수 있는 보안 취약성을 가지고 있습니다. 이 로그는 "allowPrivilegeEscalation"이 "false"로 설정되지 않았다는 것을 의미하며, 이는 보안 위험 요소일 수 있습니다.


  • POD 를 삭제하고 다시 생성하지만 파드 보안 구성이 Restricted PSS profile 을 위반하기 때문에 PSA가 workshop Namespace 에서 POD 생성을 허용하지 않습니다

  • POD 구성에 몇 가지 보안 컨트롤을 추가하여 workshop Namespace 에 대해 구성된 Privileged PSS profile 을 준수하도록 설정합니다.
helm upgrade --reuse-values  -f workshop/helm-chart/security/values-psa-pss-restricted.yaml workshop workshop/helm-chart/

  • POD가 생성되었있음을 확인합니다.
  • 파드 보안 구성이 Restricted PSS profile 을 확인하므로 PSA가 허용되었음을 나타낸다.

 

 

 

 

 

 

 

Comments