validate 규칙과 내장 정책 비교하기

목표

Kyverno ClusterPolicy 로 라벨 필수와 태그 금지 규칙을 작성하고, 같은 검사를 쿠버네티스 내장 ValidatingAdmissionPolicy 로도 실제 클러스터에 올려 두 접근의 차이를 확인합니다.

왜 중요한가

정책 엔진을 도입할지 판단하려면 내장 기능의 사정거리를 알아야 합니다. 필드 하나를 CEL 로 검사하는 것이 전부라면 ValidatingAdmissionPolicy 로 충분하고, 그러면 운영할 컴포넌트가 하나 줄고 웹훅 인증서 갱신을 신경 쓸 일도 하나 줍니다. Kyverno 를 정당화하는 것은 generate 와 mutate, 이미지 검증처럼 내장 정책이 못 하는 일들입니다. 이 실습에서 두 매니페스트를 나란히 만들어 보면 그 경계가 어디인지 손에 남습니다. 또 하나, 규칙마다 강제 수준을 다르게 주는 연습은 실제 도입 절차의 핵심입니다.

단계

1. /root/kca-validate/ 디렉터리를 만들고 policy.yaml 에 apiVersion kyverno.io/v1, kind ClusterPolicy, metadata.name kca-require-app-label 을 쓰고 spec.rules[0].name 을 check-app-label 로 하세요.
2. spec.rules[0].match.any[0].resources.kinds 에 Pod 와 Deployment 를 넣고, 같은 곳의 namespaces 에 kca-app 을 넣으세요.
3. spec.rules[0].validate.message 를 채우고, validate.pattern 으로 metadata.labels 의 app.kubernetes.io/name 이 비어 있지 않은 값이어야 한다고 요구하세요.
4. spec.rules[0].validate.failureAction 을 Enforce 로 두세요. 정책 수준 spec.validationFailureAction 은 쓰지 마세요.
5. 두 번째 규칙 deny-latest-tag 를 추가하세요. validate.message 를 채우고 validate.deny.conditions.all[0] 에 컨테이너 이미지를 가리키는 key, operator, value 를 넣은 뒤, 이 규칙의 validate.failureAction 은 Audit 으로 두세요.
6. spec.rules[0].exclude.any[0].resources.namespaces 에 kube-system 과 kyverno 를 넣으세요.
7. 클러스터에 ValidatingAdmissionPolicy kca-require-app-label 을 실제로 만드세요. spec.failurePolicy 는 Fail, spec.matchConstraints 는 apps 그룹의 deployments 를 CREATE·UPDATE 로 잡고, spec.validations[0].expression 은 app.kubernetes.io/name 라벨의 존재를 검사하는 CEL 이어야 합니다.
8. 클러스터에 네임스페이스 kca-app 을 라벨 kca=enforced 와 함께 만들고, ValidatingAdmissionPolicyBinding kca-require-app-label-binding 을 실제로 만드세요. spec.policyName 은 kca-require-app-label, spec.validationActions 에는 Deny 를, spec.matchResources.namespaceSelector.matchLabels 에는 kca: enforced 를 넣으세요.

참고

• CEL 예시로는 has(object.metadata.labels) 와 인덱싱을 조합하는 형태가 흔합니다. kubectl explain validatingadmissionpolicy.spec.validations 가 도움이 됩니다.
• 파일 확인은 yq '.spec.rules[1].validate' /root/kca-validate/policy.yaml 처럼 부분만 뽑아 보세요.
• 흔한 실수 1: spec.validationFailureAction 을 남겨 둔 채 규칙 단위 필드를 추가하는 것. 이 실습에서는 정책 수준 필드를 지워야 통과합니다.
• 흔한 실수 2: 바인딩 없이 ValidatingAdmissionPolicy 만 올리는 것. 정책은 존재해도 아무 요청도 타지 않습니다.

단계 8개

1. ClusterPolicy 골격
2. 무엇을 고를 것인가
3. 패턴 매칭으로 필수 라벨 요구
4. 규칙 단위로 강제 수준 정하기
5. deny.conditions 로 두 번째 규칙 추가
6. 시스템 네임스페이스 제외
7. 같은 규칙을 내장 정책으로
8. 바인딩과 대상 네임스페이스