정책을 썼다와 정책이 지켜진다는 다르다

한 줄 요약

Kyverno 는 막는 것이 존재 이유인데, 막는 부분이 없는 환경에서는 정책을 썼다는 사실 외에 아무것도 확인되지 않습니다.

왜 진짜 어드미션이어야 하나

앞 모듈들에서 Kyverno 정책을 여러 개 썼습니다. 그런데 그 실습들이 도는 곳은 CRD 만 적재된 클러스터라, kubectl apply 가 성공했다는 것 외에는 아무것도 확인되지 않았습니다.

Kyverno 는 어드미션 컨트롤러입니다. 막는 것이 존재 이유인데, 막는 부분이 없는 환경에서 배운 셈입니다.

세 동작은 시점이 다릅니다

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

이 순서를 알면 정책을 조합할 수 있습니다. "없으면 넣어 준다"(mutate)와 "반드시 있어야 한다"(validate)를 함께 두면 사용자는 아무것도 안 해도 통과합니다.

그리고 generate 가 어드미션 밖이라는 것이 두 가지를 낳습니다 — 별도 권한이 필요하고, 즉시 만들어지지 않습니다. 권한이 없으면 정책은 멀쩡한데 아무것도 안 만들어지고, 오류는 Kyverno 로그 안에만 있습니다.

가장 위험한 것은 조용한 실패

Kyverno 파드가 Running 이어도 웹훅 설정이 없으면 아무 일도 일어나지 않습니다. 정책은 그대로 있고 오류도 없습니다. 정책을 다 써 두고 하나도 적용되지 않은 상태가 정상처럼 보입니다.

그래서 정책을 쓴 뒤에는 반드시 막히는지 직접 시험해야 합니다.

정책 하나가 클러스터를 잠글 수 있습니다

시스템 네임스페이스를 빼지 않으면, 노드가 재시작할 때 CNI 와 CoreDNS 가 다시 만들어지지 못합니다. Kyverno 자신도 못 뜨므로 정책을 지울 수도 없습니다.

실무에서 진짜 중요한 것

정책을 배포한 뒤에는 반드시 위반하는 오브젝트로 시험합니다. 파드가 Running 이어도 웹훅 설정이 없으면 아무 일도 일어나지 않고, 오류도 나지 않습니다. 정책을 다 써 두고 하나도 적용되지 않은 상태가 정상처럼 보이는 것이 이 도구의 가장 흔한 사고입니다.

시스템 네임스페이스는 처음부터 예외로 둡니다. 빼지 않으면 노드가 재시작할 때 CNI 와 CoreDNS 가 다시 만들어지지 못하고, Kyverno 자신도 못 떠서 정책을 지울 수도 없습니다. 클러스터가 통째로 잠깁니다.

generate 가 안 만들어지면 정책이 아니라 권한을 봅니다. 어드미션 밖의 별도 컨트롤러가 하는 일이라 권한이 따로 필요하고, 실패해도 오류는 Kyverno 로그 안에만 남습니다.

다음 실습에서 이것들을 진짜 Kyverno 위에서 직접 확인합니다.