정책을 어디에서 집행할 것인가

한 줄 요약

같은 규칙이라도 집행하는 자리가 셋입니다. 파이프라인, 어드미션, 그리고 이미 떠 있는 것에 대한 감사입니다. 세 자리는 서로를 대신하지 못하고, 각자 놓치는 것이 다릅니다.

왜 한 자리로는 부족한가

파이프라인에서만 막으면 파이프라인을 거치지 않은 것이 통과합니다. 사람이 손으로 kubectl apply 를 한 경우가 그렇고, 다른 팀의 다른 파이프라인이 그렇습니다.

어드미션에서만 막으면 개발자가 문제를 배포 시점에야 알게 됩니다. 커밋하고 빌드하고 기다린 끝에 거절당하는 경험이 반복되면, 사람들은 정책을 배우는 대신 정책을 피하는 방법을 배웁니다.

감사에서만 보면 이미 떠 있는 것만 보게 됩니다. 이것도 필요합니다. 정책을 나중에 도입하면 그전에 들어온 것들이 그대로 남아 있고, 그 목록을 아는 유일한 방법이 감사이기 때문입니다.

| 자리 | 놓치는 것 | 그래서 필요한 이유 |
| --- | --- | --- |
| 파이프라인 | 파이프라인을 거치지 않은 변경 | 개발자가 가장 빨리 알게 됩니다 |
| 어드미션 | 이미 떠 있는 것 | 어떤 경로로 와도 막힙니다 |
| 감사 | 아직 안 들어온 것 | 정책 도입 이전의 잔재를 셉니다 |

어떻게 동작하나

Audit 과 Enforce 는 다른 목적입니다

정책을 처음 도입할 때 바로 Enforce 로 두면 배포가 통째로 막힙니다. 그래서 Audit 으로 시작해 얼마나 걸리는지 세고, 걸리는 것들을 고치고, 그다음에 Enforce 로 올립니다. 이 순서를 건너뛰면 정책을 롤백하게 되고, 한 번 롤백된 정책은 다시 켜기가 훨씬 어렵습니다.

거꾸로, Audit 에 영원히 머무는 정책도 흔합니다. 보고서에는 위반이 쌓이는데 아무것도 막히지 않습니다. 그래서 Audit 은 반드시 기한과 함께 둡니다.

변형과 검증은 순서가 있습니다

어드미션은 변형(mutating)이 먼저 돌고 검증(validating)이 나중에 돕니다. 그래서 "라벨이 없으면 붙여 준다" 와 "라벨이 없으면 거절한다" 를 함께 두면 앞의 것이 이깁니다. 이 순서를 모르면 검증 규칙이 왜 한 번도 발화하지 않는지 알 수 없습니다.

예외는 정책의 일부입니다

예외를 정책 밖에서 처리하면 그 예외는 아무 데도 기록되지 않습니다. 정책 엔진이 제공하는 예외 객체를 쓰면 무엇이 왜 언제까지 면제됐는지가 클러스터 안에 남습니다. 예외가 없는 정책은 대개 정책이 없는 것으로 끝납니다.

서비스 사이의 통신도 정책입니다

서비스 메시를 쓰면 워크로드 신원을 인증서로 주고, 어느 서비스가 어느 서비스를 부를 수 있는지를 선언으로 정합니다. 메시를 쓰지 않으면 같은 일을 NetworkPolicy 로 합니다. 둘의 차이는 신원의 근거입니다. NetworkPolicy 는 라벨과 IP 로 판단하고, 메시는 인증서로 판단합니다.

어느 쪽을 쓰든 시작점은 같습니다. 네임스페이스마다 기본 거부를 먼저 깔고 필요한 것만 엽니다. 아무 정책도 없는 상태가 안전한 것이 아니라 전부 열린 것입니다.

현장에서 만나는 모습

한 팀이 이미지 서명 검증 정책을 만들고 몇 달 동안 초록불을 봤습니다. 나중에 확인해 보니 정책의 match 가 특정 네임스페이스만 고르고 있었고, 실제 워크로드는 다른 네임스페이스에 있었습니다. 정책은 아무것도 검사하지 않은 채 통과하고 있었습니다.

그래서 정책을 만들었으면 막으려는 것을 실제로 넣어 보고 빨간불이 켜지는지 확인해야 합니다. 통과하는 것만 확인한 정책은 몇 달 동안 아무것도 지키지 않습니다.

그다음 읽을 것

정책이 무엇을 막는지 정한 다음, 그 판단의 근거가 되는 증거를 어떻게 남길지를 이어서 봅니다.