测验：一个标签打开 Pod 安全标准

Pod Security Standards 의 등급과 Pod Security Admission 의 모드의 관계로 옳은 것은?

• 등급이 정해지면 모드는 자동으로 결정되므로 라벨에는 등급만 적는다
• 모드는 privileged 네임스페이스에서만 고를 수 있고 다른 등급은 enforce 로 고정된다
• 무엇을 금지하는가와 위반을 어떻게 다루는가는 다른 축이라, 모드마다 다른 등급을 걸 수 있다
• 등급은 클러스터 전체에 하나만 두고 모드만 네임스페이스마다 다르게 준다

pod-security.kubernetes.io/enforce-version 을 적지 않으면 생기는 위험은?

• 등급 판이 latest 로 따라가므로 클러스터를 올린 날 매니페스트를 안 고쳤는데도 배포가 막힐 수 있다
• 라벨이 유효하지 않은 것으로 간주되어 그 네임스페이스에서 강제가 통째로 꺼진다
• 버전 없는 라벨은 privileged 로 해석되어 모든 위반 파드가 그대로 통과한다
• 네임스페이스를 만든 시점의 등급 판에 영구히 고정되어 이후 보안 강화가 반영되지 않는다

네임스페이스에 enforce: restricted 라벨을 붙였다. 이미 그 안에서 돌고 있던 위반 파드는?

• 라벨이 붙는 즉시 어드미션이 재평가해 삭제하고 이벤트에 사유를 남긴다
• 감사 어노테이션이 붙은 채 계속 돌다가 다음 노드 재시작 때 자동으로 교정된다
• 컨트롤러가 securityContext 를 채워 넣어 restricted 를 만족하도록 고쳐 준다
• 그대로 계속 돈다. 어드미션은 요청을 보는 기구라 재시작이나 재스케줄 때에야 거부된다

enforce 모드가 워크로드 리소스에 적용되지 않는다는 사실이 만드는 현상은?

• Deployment 를 만들면 즉시 거부되어 ReplicaSet 자체가 생기지 않는다
• 위반 템플릿을 가진 Deployment 는 apply 가 성공하고, 파드가 안 생기는 것은 ReplicaSet 이벤트에서 드러난다
• Deployment 는 통과하지만 audit 과 warn 도 워크로드에는 적용되지 않아 경고조차 뜨지 않는다
• 파드는 만들어지고 Deployment 쪽에서만 거부되어 두 오브젝트의 상태가 어긋난다

restricted 로 전환하기 전에 그 네임스페이스의 기존 위반을 미리 확인하는 방법은?

• 라벨 변경을 --dry-run=server 로 돌려 기존 파드의 위반을 경고로 받아 본다
• 네임스페이스를 새로 만들어 워크로드를 복제한 뒤 거기서 파드를 전부 다시 띄워 본다
• kube-apiserver 의 감사 정책을 Metadata 수준으로 올려 과거 요청을 다시 재생한다
• PodSecurityPolicy 를 잠시 되살려 같은 규칙으로 검사한 뒤 다시 제거한다

면제(exemption)에서 컨트롤러 서비스 어카운트를 면제하지 말라는 경고의 이유는?

• 서비스 어카운트 면제는 어드미션 설정이 아니라 네임스페이스 라벨로만 지정할 수 있기 때문
• 컨트롤러는 파드를 직접 만들지 않아 면제해도 아무 효과가 없고 설정만 길어지기 때문
• 대부분의 파드가 컨트롤러를 통해 만들어져서, 워크로드를 만들 수 있는 모든 사람이 암묵적으로 면제되기 때문
• 면제 대상 서비스 어카운트의 토큰이 만료되면 그 네임스페이스 전체가 강제 밖으로 나가기 때문