Watch a Policy Actually Block

이 실습은 진짜 Kyverno 에서 돕니다

VM 안에 k3s + Kyverno 가 실제로 떠 있습니다. 어드미션 웹훅이 등록되어 있어서 정책을 붙이면 정말로 거부되고, 정말로 값이 주입되며, 정말로 다른 오브젝트가 만들어집니다.

초기 정책 작성 실습은 CRD 만 적재된 가짜 클러스터에서 돕니다. 거기서는 정책을 아무리 잘 써도 아무 일도 일어나지 않습니다 — 그런데 kubectl apply 가 성공하므로 화면만 보면 정상입니다.

처음 뜨는 데 4~5분 걸립니다. Kyverno 를 설치하고 웹훅이 등록되기를 기다립니다.

예상 학습 시간은 70분입니다. 세션은 처음에 60분이므로 남은 시간을 확인하고 만료 전에 연장하세요. 이 실습은 k3s 1.35.8과 Kyverno 1.19.1에 고정되어 있습니다. 기존 정책을 읽는 연습을 위해 ClusterPolicy를 사용하지만, 이 API는 Kyverno 1.19에서 deprecated 되었고 공식 문서는 1.20에서 제거할 예정이라고 안내합니다. 새 프로젝트에 그대로 복사하지 말고 지원 버전과 새 정책 API를 확인하세요.

목표

정책의 세 동작(validate·mutate·generate)이 각각 언제 어떻게 일어나는지 직접 확인하고, Enforce 와 Audit 의 차이, 그리고 예외를 빠뜨렸을 때 무슨 일이 생기는지를 봅니다.

왜 중요한가

정책 엔진에서 가장 위험한 상태는 "정책이 틀린 것" 이 아니라 "정책이 아무 데도 적용되지 않는 것" 입니다. 후자는 조용하기 때문입니다.

그리고 세 동작은 일어나는 시점이 다릅니다.

동작	언제	무엇을
mutate	어드미션, validate 보다 먼저	오브젝트를 고친다
validate	어드미션	거절하거나 통과시킨다
generate	어드미션 뒤에, 별도 컨트롤러가	다른 오브젝트를 만든다

이 순서를 모르면 정책이 서로를 무력화합니다. mutate 가 라벨을 넣어 주는데 validate 가 그 라벨을 요구한다면, 순서 덕분에 통과합니다. 반대로 generate 는 어드미션 밖에서 일어나므로 별도의 권한이 필요합니다.

단계

파드는 kca 네임스페이스에 만듭니다.

1. Kyverno 가 어떻게 호출되는지 확인해 /root/kca/install.txt 에 담으세요. 웹훅 설정이 등록되어 있어야 합니다.
2. require-team ClusterPolicy(Enforce)로 team 라벨을 요구하고, 라벨 없는 파드가 거부되는 것과 갖춘 ok-pod 가 뜨는 것을 /root/kca/validate.txt 에 담으세요.
3. add-defaults 정책으로 파드에 owner 라벨을 주입하고, mutated 파드에 실제로 들어간 것을 /root/kca/mutate.txt 에 담으세요. mutate 와 validate 의 순서도 적습니다.
4. gen-baseline 정책으로 새 네임스페이스에 baseline ConfigMap 을 만들게 하고, tenant-x 를 만들어 확인해 /root/kca/generate.txt 에 담으세요.
5. warn-only 정책을 Audit 으로 걸고, 위반하는 violator 파드가 만들어지는 것과 PolicyReport 에 기록되는 것을 /root/kca/audit.txt 에 담으세요.
6. require-team 에 예외를 더해 시스템 네임스페이스를 빼고, 왜 그래야 하는지를 /root/kca/exclude.txt 에 담으세요.
7. /root/kca/test-pod.yaml 을 만들고 kyverno CLI 로 클러스터에 올리기 전에 시험해 /root/kca/cli.txt 에 담으세요.
8. /root/kca/report.md 에 enforce_blocks=yes, audit_blocks=no, policies= 세 줄과 설명을 쓰세요.

참고

• 정책의 동작 방식은 spec.validationFailureAction(옛 판) 또는 규칙 안의 validate.failureAction(새 판)입니다. 클러스터의 Kyverno 버전에 맞는 쪽을 쓰세요 — kubectl explain clusterpolicy.spec 으로 확인할 수 있습니다.
• 정책을 붙인 직후에는 아직 안 먹을 수 있습니다. 웹훅 설정이 갱신되기까지 몇 초 걸립니다. 시험하기 전에 잠깐 기다리세요.
• generate 는 어드미션이 아니라 백그라운드 컨트롤러가 합니다. 그래서 그 컨트롤러의 서비스어카운트에 권한이 있어야 합니다. 없으면 정책은 멀쩡한데 아무것도 안 만들어집니다.
• CLI 는 kyverno apply <정책> --resource <매니페스트> 입니다. 클러스터가 없어도 되므로 CI 에서 씁니다.
• 흔한 실수 1: 대상 범위를 넓히면서 시스템 워크로드의 라벨과 복구 경로를 확인하지 않는 것. 이 정책에 위반하는 시스템 Pod의 재생성이 막힐 수 있습니다. 규칙의 exclude와 웹훅의 namespaceSelector는 서로 다른 단계의 필터입니다.
• 흔한 실수 2: Audit 으로 걸어 두고 그 정책이 차단한다고 생각하는 것. Audit 정책은 위반을 허용하고 보고하며, 다른 Enforce 정책은 여전히 거부할 수 있습니다.

정책은 어떻게 불리는가

Kyverno 가 어떻게 호출되는지 확인해 /root/kca/install.txt 에 담으세요. 웹훅 설정이 등록되어 있어야 합니다.

ValidatingWebhookConfiguration 이 등록되어 있어야 API 서버가 Kyverno 에게 물어봅니다.

거절한다

require-team ClusterPolicy(Enforce)로 team 라벨을 요구하고, 라벨 없는 파드가 거부되는 것과 갖춘 ok-pod 가 뜨는 것을 /root/kca/validate.txt 에 담으세요.

Enforce 여야 막습니다. 라벨 없는 파드와 갖춘 파드를 둘 다 시험하세요.

고친다 — 그리고 순서가 있다

add-defaults 정책으로 파드에 owner 라벨을 주입하고, mutated 파드에 실제로 들어간 것을 /root/kca/mutate.txt 에 담으세요. mutate 와 validate 의 순서도 적습니다.

mutate 는 validate 보다 먼저 실행됩니다. 그래서 mutate 가 넣어 준 값을 validate 가 요구할 수 있습니다.

다른 것을 만든다

gen-baseline 정책으로 새 네임스페이스에 baseline ConfigMap 을 만들게 하고, tenant-x 를 만들어 확인해 /root/kca/generate.txt 에 담으세요.

generate 는 백그라운드 컨트롤러가 합니다. 그래서 그 컨트롤러에게 권한이 있어야 하고, 즉시 만들어지지 않습니다.

막지 않고 기록만 한다

warn-only 정책을 Audit 으로 걸고, 위반하는 violator 파드가 만들어지는 것과 PolicyReport 에 기록되는 것을 /root/kca/audit.txt 에 담으세요.

Audit 정책은 위반해도 오브젝트를 만들어 줍니다. 결과는 PolicyReport 에 쌓입니다.

정책 범위를 넓힐 때 예외와 복구를 확인한다

require-team 에 예외를 더해 시스템 네임스페이스를 빼고, 왜 그래야 하는지를 /root/kca/exclude.txt 에 담으세요.

앞 단계는 kca만 대상으로 삼았습니다. 이번에는 대상을 넓히되 시스템 네임스페이스를 exclude 합니다. 정책 예외만으로 웹훅 호출까지 제외되었다고 판단하지 마세요.

올리기 전에 시험한다

/root/kca/test-pod.yaml 을 만들고 kyverno CLI 로 클러스터에 올리기 전에 시험해 /root/kca/cli.txt 에 담으세요.

kyverno apply <정책> --resource <매니페스트> 는 클러스터 없이 정책을 시험합니다. CI 에서 씁니다.

무엇을 배웠나

/root/kca/report.md 에 enforce_blocks=yes, audit_blocks=no, policies= 세 줄과 설명을 쓰세요.

enforce_blocks=, audit_blocks=, policies= 세 줄과 함께 세 동작의 시점과 예외 이야기를 쓰세요.