기본값을 채워 주는 변형 정책 쓰기

목표

빠진 값을 채워 주는 변형 정책을 세 가지 방식으로 쓰고, 이미 지정된 값은 건드리지 않는다는 것을 직접 확인합니다. 마지막에는 무엇이 어떻게 바뀌었는지 대조 보고서를 만듭니다.

왜 중요한가

막기만 하는 정책은 문제를 사용자에게 떠넘깁니다. 리밋 없는 파드를 전부 거부하면 규칙은 지켜지지만 팀마다 "얼마를 넣어야 하나요"라는 질문이 생깁니다. 변형 정책은 조직의 기본값을 대신 채워 넣어 규칙을 지키면서 아무도 막지 않습니다. 다만 여기에는 넘지 말아야 할 선이 있습니다 — 사용자가 명시한 값은 절대 덮어쓰지 않는 것입니다. 팀이 cpu: 500m 이라고 적었는데 정책이 조용히 바꿔 버리면 그 팀은 자기 매니페스트를 믿을 수 없게 되고, 그때부터 정책은 신뢰가 아니라 공포의 대상이 됩니다. 그래서 추가 앵커 +() 는 문법 장식이 아니라 계약입니다. 참고로 이 환경에는 어드미션 웹훅이 돌지 않으므로 변형은 kyverno CLI 로 로컬 평가해 결과 매니페스트를 확인합니다.

단계

1. /root/policy/mutate/add-team-label.yaml 에 kind: ClusterPolicy 를 만드세요. spec.background 를 명시하고, spec.rules[0].mutate.patchStrategicMerge.metadata.labels 아래에 +(team): unassigned 를 넣으세요. 규칙 이름은 add-default-team, 매치는 pol-lab 네임스페이스의 Pod 입니다.
2. /root/policy/mutate/add-defaults.yaml 에 두 번째 정책을 만들고, +(...) 추가 앵커로 컨테이너의 resources.limits 에 cpu 와 memory 기본값을 채우는 규칙을 쓰세요. 그리고 /root/policy/mutate/out/anchors.md (150바이트 이상)에 조건 앵커 (), 추가 앵커 +(), 그리고 =() 또는 X() 의 차이를 정리하세요.
3. 같은 add-defaults.yaml 에 mutate.patchesJson6902 를 쓰는 규칙을 하나 더 넣으세요. op: add 와 path: /spec/containers/0/imagePullPolicy, value: IfNotPresent 형태입니다. 그리고 /root/policy/mutate/out/json6902-note.txt 에 이 방식이 배열·인덱스를 다룰 때 왜 필요한지 적으세요.
4. add-defaults.yaml 에 mutate.foreach 규칙을 넣으세요. list: "request.object.spec.containers" 로 컨테이너 목록을 받고, 내부에서 element 변수로 현재 항목을 가리켜야 합니다.
5. 두 정책을 /opt/lab/fixtures/policy/resources/bad-pod.yaml 에 적용하고, 변형된 Pod 매니페스트를 /root/policy/mutate/out/mutated.yaml 로 저장하세요. 그 파일에는 metadata.labels.team, spec.containers[0].resources.limits.memory, spec.containers[0].imagePullPolicy 세 값이 모두 채워져 있어야 합니다.
6. 같은 두 정책을 /opt/lab/fixtures/policy/resources/good-pod.yaml 에 적용해 /root/policy/mutate/out/preserved.yaml 로 저장하세요. 이 파드에는 원래 team: platform 라벨과 cpu: 500m 제한이 있으며, 변형 뒤에도 그대로여야 합니다.
7. /root/policy/mutate/mutate-existing.yaml 을 만드세요. spec.mutateExistingOnPolicyUpdate: true 를 두고, 규칙의 mutate.targets 에 kind: Pod, namespace: pol-lab 을 적어 트리거가 아닌 리소스를 고치게 하세요. 그리고 /root/policy/mutate/out/existing-note.txt 에 이 동작이 백그라운드에서 돌기 때문에 추가 RBAC 권한이 필요하다는 점을 적으세요.
8. /root/policy/mutate/out/mutate-report.json 을 만드세요. 최상위 mutations 배열에 3건 이상을 담고, 각 항목은 field·before·after·rule 네 키를 가져야 합니다. before 와 after 가 같은 항목은 넣지 마세요. field 에 team 이 들어간 항목의 after 값은 5번에서 만든 mutated.yaml 의 metadata.labels.team 값과 정확히 같아야 합니다.

참고

• 정책 파일 여러 개를 한 번에 넘길 수 있습니다: kyverno apply <정책1> <정책2> --resource <매니페스트>.
• 변형 결과 매니페스트는 출력 옵션으로 받거나, 출력에서 Pod 문서 부분만 잘라 저장하면 됩니다. 채점은 그 파일이 올바른 Pod YAML 인지만 봅니다.
• +() 는 "없으면 넣기", () 는 "조건이 맞을 때만 적용"입니다. 둘은 다른 일을 합니다.
• 흔한 실수 1: team 라벨을 앵커 없이 그냥 적는 것. 그러면 6번에서 platform 이 덮어써져 실패합니다.
• 흔한 실수 2: 8번 보고서에 값이 안 바뀐 필드를 채워 넣는 것. 변형이 아닌 것은 보고서에 들어가면 안 됩니다.

단계 8개

1. 라벨을 덧붙이는 변형 정책 만들기
2. 추가 앵커로 자원 기본값 채우기
3. JSON 패치로 배열 항목 고치기
4. 컨테이너 목록을 도는 규칙 쓰기
5. 정책을 돌려 변형 결과 저장하기
6. 이미 있는 값이 보존되는지 확인하기
7. 이미 존재하는 리소스를 고치는 정책 쓰기
8. 변형 전후 대조 보고서 만들기