测验：Kubernetes 自己做检查

ValidatingAdmissionPolicy 를 만들었는데 아무 요청도 막히지 않는다. 가장 먼저 확인할 것은?

• 대응하는 ValidatingAdmissionPolicyBinding 이 있는지 — 바인딩 없는 정책은 조용히 아무것도 막지 않는다
• 정책 파드가 떠 있는지 — VAP 는 전용 컨트롤러 파드가 평가를 맡는 구조다
• 웹훅 설정의 CA 번들이 올바른지 — VAP 도 결국 TLS 로 외부 호출을 한다
• 감사 로그 수집기가 켜져 있는지 — 수집기가 없으면 판정 자체가 건너뛰어진다

정책 로직과 적용 범위를 정책·바인딩 두 오브젝트로 나눠 둔 실질적인 이득은?

• 정책 YAML 의 길이가 줄어 API 서버의 etcd 사용량을 절반으로 낮출 수 있다
• 같은 정책을 범위와 파라미터만 달리해 여러 번 켤 수 있고, 경고에서 차단으로 옮길 때 정책 본문을 안 건드려도 된다
• 바인딩이 있는 정책은 변형(mutating) 단계에서도 평가되어 기본값 주입까지 함께 처리된다
• 정책과 바인딩이 서로 다른 네임스페이스에 있어야 클러스터 범위 자원까지 검사할 수 있다

validationActions 에 대한 설명으로 옳은 것은?

• Deny 는 정책에, Warn 과 Audit 은 바인딩에 각각 따로 적는다
• 세 값 중 하나만 고를 수 있고 동시에 두 개를 적으면 등록이 거부된다
• Deny 와 Warn 은 함께 쓸 수 없지만 Warn 과 Audit 은 함께 쓸 수 있다
• Audit 을 적으면 위반 요청이 거부되면서 감사 이벤트에도 함께 남는다

matchConditions 의 조건식이 평가 중 오류로 끝났다. failurePolicy: Ignore 인 정책은 어떻게 되는가?

• 조건이 참이었다고 보고 정책을 끝까지 평가한 뒤 결과대로 판정한다
• 요청을 거부하되 거부 사유를 감사 이벤트로만 남기고 사용자에게는 알리지 않는다
• API 서버가 조건식을 다시 평가하고, 두 번째도 실패하면 그때 요청을 거부한다
• 요청은 그대로 진행되고 그 정책만 건너뛴다

거부 메시지가 failed expression: object.spec.replicas <= 5 로만 나와 문의가 쌓인다. 정책 쪽에서 할 일은?

• validationActions 를 Audit 으로 낮춰 사용자에게 메시지가 전달되지 않게 한다
• messageExpression 으로 실제 값이 박힌 문장을 만들고, 긴 식은 spec.variables 에 이름을 붙여 재사용한다
• matchConstraints 의 범위를 넓혀 더 많은 요청이 같은 메시지를 받게 통일한다
• paramRef 의 parameterNotFoundAction 을 Allow 로 바꿔 메시지 생성을 건너뛴다

바인딩의 paramRef 를 쓸 때 반드시 지켜야 하는 것은?

• name 과 selector 를 둘 다 적어야 파라미터를 못 찾았을 때 대체 경로가 생긴다
• 파라미터 리소스는 반드시 클러스터 범위 CRD 여야 하고 네임스페이스 범위는 쓸 수 없다
• policyName 을 생략하면 같은 네임스페이스의 정책이 자동으로 연결된다
• name 과 selector 중 하나만 쓰고, parameterNotFoundAction 을 반드시 적는다