포드 보안 정책에서 마이그레이션: 종합 가이드(1부: PSA로 전환)

소개

Kubernetes가 선도적인 컨테이너 오케스트레이션 플랫폼으로 계속 발전함에 따라 보안은 컨테이너화된 애플리케이션을 배포하는 조직의 가장 중요한 관심사로 남아 있습니다. Kubernetes의 보안 무기고에 있는 기본 도구 중 PSP(Pod Security Policies)는 한때 중추적인 역할을 했습니다. PSP를 통해 관리자는 포드에 대한 보안 제약 조건을 세심하게 정의하고 시행하여 특정 보안 표준을 충족하는 컨테이너만 클러스터 내에서 작동할 수 있도록 했습니다.

그러나 Kubernetes 보안 환경은 빠르게 발전하고 있으며 PSP는 이제 Kubernetes 1.25부터 더 이상 사용되지 않습니다(Kubernetes 1.25 긴급 릴리스 노트 링크 참조). 이러한 변화는 PSP 정책 관리 및 유지의 복잡성을 비롯한 다양한 요인에서 비롯되며 종종 사용자의 운영 문제로 이어집니다.

지원 중단에 대응하여 조직은 이제 보안 요구 사항을 해결할 뿐만 아니라 Kubernetes 의 워크로드 보안 프로세스를 간소화하는 PSP에 대한 현대적인 대안을 찾고 있습니다.

이 종합 가이드에서는 PSA(Pod Security Acceptance)로의 전환에 중점을 두고 Kubernetes 보안 관행의 이러한 변화를 탐색하는 여정을 시작합니다. PSA는 사용 가능한 가장 강력한 대안 중 하나이며 이 기사에서는 이에 대해 심층적으로 살펴봅니다. 그러나 다른 두 가지 대안인 Kyverno와 OPA Gatekeeper에 대해서는 이 시리즈의 별도 기사에서 다룰 예정입니다.

이 문서 전체에는 PSA 설정 및 설치에 대한 자세한 지침, PSP에서 PSA로 원활하게 전환하기 위한 단계별 마이그레이션 가이드, 기존 PSP 규칙을 PSA로 전송하기 위한 정확한 명령이 나와 있습니다. 또한 PSA에 맞춰진 테스트 실행 명령을 사용하여 네임스페이스의 마이그레이션 준비 상태를 평가하는 방법을 배우게 됩니다.

이 가이드를 마치면 PSA의 장점과 한계를 포괄적으로 이해하게 되어 조직의 특정 보안 요구 사항과 Kubernetes 환경을 기반으로 정보에 입각한 결정을 내릴 수 있게 됩니다.

이 가이드를 사용하면 Kubernetes 보안 관행을 자신있게 현대화하여 Pod 보안 정책 시대에 작별을 고하는 동안 워크로드를 계속 보호할 수 있습니다.

포드 보안 승인(PSA)

• PSA는 Kubernetes 보안 표준을 시행합니다. PSA는 컨테이너가 포드 보안 표준에 정의된 Kubernetes의 기본 보안 표준을 준수하도록 보장합니다. 이러한 표준은 보안 정책을 세 가지 프로필로 분류하며 각각 제한 수준이 다릅니다.

  
  

  • 권한 있음 : 권한 있음 정책은 의도적으로 개방되어 있으며 완전히 제한되지 않습니다. 일반적으로 이 정책은 신뢰할 수 있는 사용자가 관리하는 시스템 및 인프라 수준 워크로드를 대상으로 합니다. 제한이 없는 것이 특징입니다. Gatekeeper와 같은 기본 허용 메커니즘은 본질적으로 권한이 있을 수 있지만 PSP(팟 보안 정책)와 같은 기본 거부 메커니즘의 경우 권한 정책은 모든 제한 사항을 비활성화해야 합니다.

  • 기준 : 기준 정책은 알려진 권한 에스컬레이션을 방지하면서 일반적인 컨테이너화된 워크로드에서 쉽게 채택할 수 있도록 설계되었습니다. 중요하지 않은 애플리케이션의 애플리케이션 운영자 및 개발자에게 적합합니다.

  • 제한됨 : 제한됨 정책은 일부 호환성이 희생될 수 있지만 엄격한 포드 강화 모범 사례를 시행하는 데 중점을 둡니다. 주로 보안이 중요한 애플리케이션의 운영자와 개발자는 물론 신뢰도가 낮은 사용자를 대상으로 합니다. 각 프로필에 적용되거나 허용되지 않는 통제 항목의 전체 목록을 보려면 공식 문서를 참조하세요.

    
    

• 직접적인 PSP 규칙 전송 없음: 다른 솔루션과 달리 PSA는 PSP(팟 보안 정책) 규칙을 직접 마이그레이션하거나 수정하는 간단한 방법을 제공하지 않습니다. PSA의 주요 초점은 위에서 언급한 프로필을 포함하여 확립된 Kubernetes 보안 표준 에 대해 포드를 검증하는 것입니다.

• 돌연변이 없음 : PSA는 검증에 효과적이지만 PSP처럼 포드 사양을 수정하거나 사용자 정의할 수는 없습니다. PSA의 주요 목적은 사전 정의된 Kubernetes 보안 표준을 시행하는 것이며 포드 사양을 변경하거나 변경하는 기능은 포함하지 않습니다. 주로 이러한 확립된 표준에 따라 포드를 검증하는 데 중점을 둡니다.

설정 및 설치

PSA는 Kubernetes 기본 구성 요소이므로 작동하게 하려면 PSA(Pod Security Acceptance) 컨트롤러가 Kubernetes 클러스터에서 활성화되어 있는지 확인하기만 하면 됩니다. 다음 명령을 실행하면 됩니다.

kubectl api-versions | grep admission

마이그레이션 준비 단계

네임스페이스 권한 평가

포드 보안 승인 제어는 네임스페이스 레이블의 영향을 받습니다. 이는 네임스페이스를 업데이트, 패치 또는 생성할 수 있는 권한을 가진 개인이 해당 네임스페이스에 대한 포드 보안 설정을 수정할 권한도 있음을 의미합니다. 이러한 수정은 잠재적으로 더 엄격한 보안 정책을 우회할 수 있습니다. 계속하기 전에 네임스페이스 권한이 신뢰할 수 있고 권한이 있는 사용자에게만 할당되었는지 확인하는 것이 중요합니다. 그러한 액세스가 필요하지 않은 사용자에게는 이러한 높은 권한을 부여하지 않는 것이 좋습니다. 네임스페이스 객체에 포드 보안 라벨을 구성하는 데 추가 제약 조건이 필요한 경우 허용 웹훅을 활용하여 이러한 제한 사항을 적용하는 것이 좋습니다.

PodSecurityPolicy 간소화 및 표준화

PSA(Pod Security Acceptance)로 마이그레이션하기 전에 PSP(PodSecurityPolicy)를 정규화하는 것이 좋습니다.

• 지원되지 않는 필드 제거 : 포드 보안 표준에서 다루지 않는 옵션을 제거합니다. 이러한 옵션에는 다음이 포함됩니다.

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• 순전히 변경되는 필드 제거 : 변경 효과만 있고 유효성 검사 정책에 영향을 주지 않는 필드를 제거하여 프로세스를 시작합니다. "PodSecurityPolicies를 Pod 보안 표준에 매핑" 참조에도 언급된 대로 이러한 필드에는 다음이 포함됩니다.

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

적합한 포드 보안 수준 결정

네임스페이스에 적합한 포드 보안 수준을 결정할 때 고려해야 할 몇 가지 방법이 있습니다.

네임스페이스에 대한 보안 요구 사항별

네임스페이스에 대한 예상 액세스 수준과 보안 요구 사항을 잘 알고 있는 경우 해당 특정 요구 사항에 따라 적절한 포드 보안 수준을 선택할 수 있습니다. 이 접근 방식은 새 클러스터의 보안 설정에 접근하는 방법과 유사합니다.

기존 PodSecurityPolicy 기준:

"PodSecurityPolicies를 포드 보안 표준에 매핑" 참조를 활용하여 기존 포드 보안 정책(PSP) 각각을 해당 포드 보안 표준 수준에 매핑합니다.
PSP가 원래 Pod 보안 표준을 기반으로 하지 않는 경우 결정을 내려야 할 수도 있습니다. 최소한 PSP만큼 허용적인 포드 보안 수준을 선택하거나 최소한 제한적인 수준을 선택하세요. 특정 네임스페이스 내의 포드에 사용 중인 PSP를 식별하려면 다음 명령을 사용합니다.

 kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u

기존 포드별:

테스트 실행을 수행하고 다음 섹션의 label 명령을 적용하여 기준 및 제한된 포드 보안 수준을 모두 테스트합니다. 이는 이러한 수준이 기존 워크로드에 대해 충분히 허용되는지 여부를 평가하는 데 도움이 됩니다. 기존 워크로드에 맞는 최소 권한의 유효한 수준을 선택하세요.

포드 보안 수준 테스트

네임스페이스에 대한 포드 보안 수준(권한 수준 제외)을 결정한 후에는 선택한 정책을 검증하는 것이 중요합니다. Pod Security는 원활한 롤아웃과 보안 표준 준수를 보장하는 테스트 옵션을 제공합니다.

테스트 실행 테스트:

즉각적인 시행 없이 선택한 정책의 영향을 평가하려면 이 방법을 사용하십시오.
연습 실행을 수행하려면 다음 명령을 사용하여 지정된 정책 수준을 충족하지 않는 기존 포드를 강조 표시합니다.

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

감사 모드 테스트:

감사 모드를 사용하면 정책 위반을 시행하지 않고 기록할 수 있습니다. 위반 포드는 나중에 검토할 수 있도록 감사 기록에 기록됩니다. 다음 명령을 사용하여 감사 모드를 활성화합니다.

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

테스트 중에 예상치 못한 정책 위반이 발생하는 경우 다음을 수행할 수 있습니다.

• 정책에 맞게 비준수 워크로드를 업데이트합니다.
• 워크로드 요구 사항을 수용하기 위해 필요한 경우 네임스페이스의 포드 보안 수준을 조정합니다.

포드 보안 수준 시행

선택한 포드 보안 수준이 네임스페이스에 적합하다고 확신하면 계속해서 적용할 수 있습니다. 이 단계를 수행하면 원하는 보안 표준이 네임스페이스 내의 워크로드에 적극적으로 적용됩니다.

네임스페이스에 원하는 포드 보안 수준을 적용하려면 다음 명령을 사용합니다.

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

이 명령을 실행하면 지정된 포드 보안 수준이 활성화 및 시행되어 네임스페이스의 보안 상태가 강화됩니다.

PSP 우회

네임스페이스 수준에서 PodSecurityPolicy를 효과적으로 우회하려면 전체 권한이 있는 PSP(팟 보안 정책)를 네임스페이스의 모든 서비스 계정에 바인딩할 수 있습니다. 이 프로세스를 통해 네임스페이스 내의 Pod가 더 이상 PodSecurityPolicy에 의해 부과된 수정 또는 제한 사항에 적용되지 않습니다. 클러스터 수준이나 개별 네임스페이스 수준에서 이를 수행할 수 있습니다.

클러스터 범위 설정(전체 클러스터에 대해 한 번만 필요):

privileged-psp.yaml 과 같은 YAML 구성 파일을 적용하여 전체 권한이 있는 PSP(팟 보안 정책)를 생성합니다. 이 PSP는 포드에 필요한 모든 권한을 부여하고, PSP(팟 보안 정책) 사용을 허용하고 권한 있는 PSP와 연결하기 위해 Privilege-psp라는 클러스터 역할을 생성해야 합니다.

 kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

네임스페이스별 비활성화:

Privilege-psp 클러스터 역할을 system:serviceaccounts:$NAMESPACE 그룹과 연결하려면 대상 네임스페이스에 역할 바인딩을 만듭니다. 이 바인딩은 PodSecurityPolicy를 우회하여 네임스페이스 내의 모든 서비스 계정에 전체 권한이 있는 PSP에 대한 액세스 권한을 효과적으로 부여합니다.

 kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

이 설정을 사용하면 권한 있는 PSP는 변경되지 않으며 PodSecurityPolicy 허용 컨트롤러는 항상 변경되지 않는 PSP의 우선순위를 지정합니다. 결과적으로 이 네임스페이스의 Pod는 더 이상 PodSecurityPolicy에 의해 수정되거나 제한되지 않습니다.

이 접근 방식의 한 가지 장점은 가역성입니다. 문제가 발생하면 PodSecurityPolicy 비활성화와 관련된 RoleBinding을 삭제하여 변경 사항을 쉽게 롤백할 수 있습니다. 이 프로세스 중에 기존 포드 보안 정책이 그대로 유지되는지 확인하십시오.

PodSecurityPolicy 비활성화 실행 취소:

네임스페이스에 대한 PodSecurityPolicy 비활성화를 되돌리려면 이전에 생성한 RoleBinding을 삭제하면 됩니다.

 kubectl delete -n $NAMESPACE rolebinding disable-psp

네임스페이스 생성 프로세스 재검토

Pod 보안 승인을 적용하기 위해 기존 네임스페이스를 업데이트한 경우 새 네임스페이스 생성을 위한 프로세스와 정책을 검토하고 업데이트하는 것이 중요합니다. 이렇게 하면 처음부터 적절한 포드 보안 프로필을 사용하여 새 네임스페이스가 구성됩니다.
네임스페이스 생성 프로세스를 향상하려면 다음 단계를 고려하십시오.

1. 네임스페이스 생성 정책 조정 : 원하는 포드 보안 수준의 선택 및 적용을 포함하도록 새 네임스페이스 생성에 대한 조직의 정책 및 절차를 업데이트합니다. 보안 표준이 생성 단계부터 바로 확립되었는지 확인하세요.

2. 정적 구성: 레이블이 지정되지 않은 네임스페이스에 대한 기본 적용, 감사 및/또는 경고 수준을 정의하도록 포드 보안 허용 컨트롤러를 정적으로 구성할 수 있습니다. 이 접근 방식을 사용하면 명시적인 포드 보안 라벨이 없는 네임스페이스가 기본적으로 지정된 보안 표준을 계속 준수할 수 있습니다.

   
   

   네임스페이스 생성 프로세스를 재검토하면 Pod 보안 표준을 Kubernetes 환경 에 원활하게 통합하고 기존 및 신규 네임스페이스 전체에서 일관되고 안전한 접근 방식을 유지할 수 있습니다.

PodSecurityPolicy 비활성화

PodSecurityPolicy(PSP) 승인 컨트롤러가 더 이상 필요하지 않고 PSA(팟 보안 승인)가 성공적으로 구현 및 검증되었음을 확신하면 PSP 승인 컨트롤러 비활성화를 진행할 수 있습니다.

PSP 승인 컨트롤러를 비활성화하는 단계는 다음과 같습니다.

kube-apiserver 구성 수정:

• 일반적으로 /etc/kubernetes/manifests/kube-apiserver.yaml.
• PSP 승인 컨트롤러를 비활성화하려면 --disable-admission-plugins 플래그를 추가하세요. 활성 승인 플러그인 목록에서 제거되었는지 확인하세요.

 kube-apiserver --disable-admission-plugins=PodSecurityPolicy

• 구성 파일을 저장합니다.

kube-apiserver를 다시 시작합니다.

• 변경 사항을 적용하려면 kube-apiserver를 다시 시작하세요. 일반적으로 Kubernetes 제어 플레인 또는 kube-apiserver Pod 자체를 다시 시작하여 이를 달성할 수 있습니다.

 systemctl restart kubelet

확인:

• kube-apiserver 로그 또는 해당 상태를 확인하여 PSP 승인 컨트롤러가 비활성화되어 있는지 확인하세요.

PSP로 롤백할 필요가 없다고 확신할 만큼 충분한 "잠금 시간"을 거친 후 다음 단계로 진행합니다.

PSP 리소스 정리:

PSP 허용 컨트롤러가 비활성화되고 PSA가 실행되면 기존 PodSecurityPolicy는 물론 관련 역할, ClusterRoles, RoleBinding 및 ClusterRoleBinding을 안전하게 삭제할 수 있습니다.

 kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true

이 정리 단계에서는 클러스터에 잔여 PSP 구성이 없는지 확인합니다.

PSP 승인 컨트롤러를 비활성화하고 PSP 관련 리소스를 제거하면 클러스터의 보안 아키텍처를 단순화하여 포드 보안 승인으로의 전환을 완료할 수 있습니다.

요약

이 종합 가이드에서는 Kubernetes 클러스터의 보안 프레임워크를 PSP(팟 보안 정책)에서 PSA(팟 보안 승인)로 원활하게 전환하기 위한 필수 단계와 고려 사항을 살펴보았습니다. 이 마이그레이션을 통해 Kubernetes의 진화하는 보안 표준에 맞춰 워크로드가 계속해서 안전하게 실행될 수 있습니다.

포드 보안 승인(PSA) 사용의 장단점

장점:

• 기본 Kubernetes 구성 요소 : PSA는 Kubernetes의 필수 부분이므로 타사 도구를 설치할 필요가 없습니다. 이는 플랫폼에 내장된 보안 기능을 활용합니다.
• Kubernetes 표준 시행 : PSA는 Kubernetes의 기본 보안 표준을 준수하여 플랫폼의 모범 사례를 준수하도록 보장합니다.

단점:

• 제한된 사용자 정의 : PSA는 특히 포드 사양의 변경이 필요한 복잡한 보안 정책의 경우 PSP와 동일한 수준의 사용자 정의를 제공하지 않을 수 있습니다.
• 개조 필요 : 보안 컨텍스트 설정을 포함하도록 기존 워크로드를 업데이트해야 하며, 이를 위해서는 YAML 파일 수정이 필요할 수 있습니다.

이 가이드는 PSP에서 PSA로 자신있게 마이그레이션하는 데 필요한 지식과 단계를 제공하여 Kubernetes 워크로드를 보호하는 동시에 안전하고 효율적인 전환을 보장합니다. Kyverno 및 OPA Gatekeeper로의 대체 마이그레이션 경로를 탐색할 예정인 기사를 계속 지켜봐 주시기 바랍니다.