クイズ: プラットフォームのセキュリティ

PodSecurityPolicy 가 제거되고 PSA 로 대체된 가장 큰 이유는?

• PSP 가 성능 오버헤드를 너무 많이 발생시켰기 때문
• PSP 가 네임스페이스 단위로만 동작해 표현력이 부족했기 때문
• PSP 가 CRD 기반으로 구현돼 API 서버를 업그레이드할 때마다 깨졌기 때문
• PSP 는 RBAC 으로 정책과 주체를 연결하는 구조라 어느 정책이 적용됐는지 알기 어렵고 mutating 이라 디버깅이 지극히 어려웠기 때문

restricted 프로파일을 통과하기 위해 반드시 필요한 설정 조합은?

• privileged=false, hostNetwork=false, readOnlyRootFilesystem=true
• runAsUser=0, capabilities.add=[NET_ADMIN], hostPID=false
• runAsNonRoot=true, allowPrivilegeEscalation=false, capabilities.drop=[ALL], seccompProfile.type=RuntimeDefault
• automountServiceAccountToken=false, imagePullPolicy=Always

네임스페이스의 enforce 라벨을 baseline 에서 restricted 로 올렸다. 이미 그 네임스페이스에서 돌고 있던 위반 파드는?

• 즉시 종료되고 재생성이 차단된다
• 자동으로 스펙이 수정되어 정책에 맞게 바뀐다
• 그대로 계속 실행된다. PSA 는 어드미션 시점에만 판단하기 때문
• audit 로그에만 기록되고 다음 노드 재시작 때 종료된다

pod-security.kubernetes.io/enforce-version 라벨을 명시적으로 고정해야 하는 이유는?

• 고정하지 않으면 latest 로 동작해, 클러스터 업그레이드만으로 정책 내용이 바뀌어 배포한 적 없는 워크로드가 거부될 수 있기 때문
• 고정하지 않으면 PSA 가 아예 동작하지 않기 때문
• 버전 라벨이 붙어 있어야 PSA 의 audit 로그가 제대로 기록되기 때문
• 버전마다 라벨 키 이름이 달라지기 때문

PSA 의 면제(exemptions)에 대한 설명으로 올바른 것은?

• 네임스페이스에 exempt 라벨을 붙여 설정한다
• usernames·runtimeClasses·namespaces 세 축이 있으며 apiserver 의 AdmissionConfiguration 에 설정하므로 네임스페이스 관리자가 스스로를 면제할 수 없다
• Role 을 만들어 면제 권한을 부여한다
• 면제는 audit 와 warn 모드에만 적용되고 enforce 모드에는 적용되지 않으므로 실제 차단은 그대로 일어난다

시크릿 관리의 성숙도를 판단하는 기준으로 저자가 제시한 핵심 질문은?

• 시크릿이 어떤 암호화 알고리즘과 키 길이로 보호되는가
• 시크릿 스캐너를 몇 개나 파이프라인에 붙였는가
• 이 자격증명이 지금 공개됐다고 가정할 때 폐기하고 새 값으로 교체해 서비스를 정상화하는 데 몇 분이 걸리는가
• 시크릿이 몇 개의 저장소에 분산되어 있는가