クイズ: ポリシーの運用

새 정책을 도입하는 표준 절차로 가장 적절한 것은?

• 처음부터 Enforce 로 걸고 문제가 생기면 예외를 추가한다
• 개발 클러스터에서만 Enforce 로 걸고 프로덕션은 영원히 Audit 으로 둔다
• Audit 으로 며칠 돌려 PolicyReport 의 걸리는 목록이 예상과 일치하는지 확인한 뒤 Enforce 로 올린다
• 정책 없이 코드 리뷰로만 강제한다

validationFailureActionOverrides 와 규칙 단위 failureAction 의 관계로 옳은 것은?

• 둘은 같은 기능이고 하나만 쓰면 된다
• 오버라이드가 규칙 단위 설정을 무시하고 언제나 우선 적용된다
• 오버라이드는 mutate 규칙에만 적용된다
• 규칙 단위는 어느 규칙을 강제할지, 오버라이드는 어느 네임스페이스에서 강제할지를 정한다. 두 축을 조합할 수 있다

spec.applyRules 를 One 으로 두었을 때의 동작은?

• 규칙이 하나만 있는 정책만 로드된다
• 매칭된 리소스에 첫 번째로 매칭된 규칙만 적용하고 멈춘다
• 규칙을 하루에 한 번만 평가한다
• PolicyReport 에 결과를 한 건만 남긴다

kyverno apply policy.yaml --resource pod.yaml 을 CI 게이트로 쓸 수 있는 이유는?

• 정책을 자동으로 Enforce 로 승격시켜 주기 때문
• PolicyReport 오브젝트를 클러스터에 생성해 주기 때문
• 클러스터에 접속하지 않고도 실행되며, 실패나 에러가 있으면 종료 코드가 1이라 잡이 멈춘다
• 매치되지 않는 정책을 자동으로 고쳐 주기 때문

PolicyException 을 쓸 때 지켜야 할 원칙으로 가장 중요한 것은?

• 정책 이름과 규칙 이름, 그리고 이름 패턴까지 좁혀 지목한다. 예외가 도는 대상의 절반을 넘어가면 그 정책은 보안이 있다는 착각만 준다
• 예외는 항상 클러스터 전체 범위로 만든다
• 예외를 주어야 할 네임스페이스에서는 그 정책 자체를 아예 삭제해 둔다
• 예외는 mutate 규칙에만 적용한다

파드 보안 수준(루트 금지, 권한 상승 금지, 케이퍼빌리티 제거 등)을 강제할 때 Kyverno 없이도 가능한 방법은?

• ResourceQuota 에 보안 항목을 추가한다
• NetworkPolicy 로 파드 권한을 제한한다
• 네임스페이스에 Pod Security Admission 라벨을 붙인다. enforce·audit·warn 세 모드와 버전 라벨로 표준 등급을 강제할 수 있다
• 파드가 쓰는 ServiceAccount 에 securityContext 를 지정해 강제한다