Kyverno 마스터 클래스: AdmissionReview 데이터 추출부터 외부 데이터 연동까지

안녕하세요! 쿠버네티스 클러스터에 지능을 불어넣는 시간, Kyverno 마스터 시리즈의 다섯 번째 시간입니다. 🧠

지금까지 우리는 정적인 정책, 즉 "이 리소스는 안 돼!", "이 레이블은 꼭 있어야 해!" 같은 고정된 규칙을 배웠습니다. 하지만 실무에서는 훨씬 복잡한 상황이 발생하죠. 예를 들어, "로그인한 사용자의 이름에 따라 다른 설정을 넣고 싶을 때"나, "우리 회사의 표준 팀 리스트가 적힌 ConfigMap을 참고해서 검증하고 싶을 때"는 어떻게 해야 할까요?

오늘의 주제는 바로 Kyverno 정책의 유연성을 극대화해 주는 변수(Variables) 활용 기술입니다. 10분만 집중해서 정책에 '지능'을 더해봅시다! 🚀

---

🏗️ 1. 변수란 무엇이며 왜 필요한가요?

Kyverno에서 변수는 정책이 실행되는 '그 순간'의 데이터를 가져오는 통로입니다.

• Admission Review 데이터: 요청을 보낸 사람이 누구인지, 어떤 IP에서 왔는지 등 실시간 정보를 가져옵니다.
• 외부 데이터 참조: 클러스터에 이미 저장된 ConfigMap의 데이터를 정책의 검증 기준으로 삼습니다.

변수를 사용하면 정책 하나로 수십 가지 상황에 유연하게 대응할 수 있습니다. 🛠️

---

🧑‍💻 2. Admission Review 데이터 활용하기

쿠버네티스 API 서버가 Kyverno에게 요청을 보낼 때, AdmissionReview라는 거대한 데이터를 함께 보냅니다. 여기에는 요청에 대한 모든 정보가 담겨 있습니다.

주요 사용 변수

• {{ request.userInfo.username }}: 요청을 보낸 사용자 이름
• {{ request.object.metadata.name }}: 생성하려는 리소스의 이름
• {{ request.namespace }}: 리소스가 생성될 네임스페이스

실전 예제: 생성자 이름을 레이블로 자동 추가하기 (Mutate)

누가 이 Pod을 만들었는지 자동으로 기록하고 싶을 때 유용합니다.

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-creator-label
spec:
  rules:
  - name: add-user-id
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            created-by: "{{ request.userInfo.username }}" # 변수 활용!

---

📚 3. ConfigMap 데이터 참조 방법 (Context 활용)

정책 안에 수많은 데이터를 직접 하드코딩하는 것은 관리상 최악입니다. 대신, 표준 데이터는 ConfigMap에 관리하고 Kyverno가 이를 읽어오게 할 수 있습니다. 이를 Context라고 부릅니다.

작동 순서

1. 표준 데이터를 담은 ConfigMap을 생성합니다.
2. 정책의 context 섹션에서 해당 ConfigMap을 선언합니다.
3. 정책 본문에서 {{ <변수명>.data.<키> }} 형식으로 참조합니다.

실전 예제: 허용된 팀 리스트만 사용하게 제한하기 (Validate)

1) 먼저 기준이 될 ConfigMap을 만듭니다.

YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-teams
  namespace: kyverno
data:
  teams: "frontend,backend,devops,security"

2) 정책에서 이 ConfigMap을 참조합니다.

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: validate-team-list
spec:
  rules:
  - name: check-team-label
    context:
    - name: team-config # 컨텍스트 이름 정의
      configMap:
        name: allowed-teams
        namespace: kyverno
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "The team label must be one of: {{ team-config.data.teams }}"
      deny:
        conditions:
          all:
          - key: "{{ request.object.metadata.labels.team }}"
            operator: NotIn
            value: "{{ team-config.data.teams }}" # ConfigMap 데이터와 비교!

---

🧩 4. JMESPath를 활용한 고급 변수 처리

Kyverno는 변수 데이터를 가공하기 위해 JMESPath라는 쿼리 언어를 사용합니다.

• 기본값 설정: 만약 변수가 비어있을 때 대신 사용할 값을 지정합니다.
  • {{ request.object.metadata.labels.env || 'default' }}
• 문자열 합치기: 여러 변수를 조합합니다.
  • {{ request.namespace }}-{{ request.object.metadata.name }}

---

🚀 5. 운영자를 위한 실무 팁 (Best Practices)

1. 네임스페이스 주의: ConfigMap을 참조할 때, 정책이 ClusterPolicy라면 ConfigMap이 어느 네임스페이스에 있는지 정확히 명시해야 합니다. (주로 kyverno 네임스페이스 권장)
2. 보안: AdmissionReview 데이터 중 userInfo는 위조하기 어려우므로, 이를 기반으로 한 정책은 보안성이 높습니다.
3. 성능: 대규모 클러스터에서 너무 많은 ConfigMap을 수시로 참조하면 API 서버에 부하가 갈 수 있습니다. 자주 바뀌지 않는 데이터 위주로 사용하세요.
4. 디버깅: 변수가 제대로 작동하는지 확인하려면 Kyverno 로그를 보거나, validationFailureAction: Audit 모드로 먼저 테스트해 보는 것이 필수입니다.

---

🌟 마치며

오늘은 Kyverno 정책에 생명력을 불어넣는 변수 활용 기술을 배웠습니다. 이제 여러분은 단순히 "안 돼"라고 말하는 정책이 아니라, "사용자 X가 보낸 요청은 Y 데이터베이스를 참고했을 때 규정에 어긋나"라고 말하는 지능적인 정책을 만들 수 있습니다. 💪

변수와 ConfigMap을 자유자재로 다루게 되면, 쿠버네티스 거버넌스의 수준이 한 단계 업그레이드됩니다.

다음 시간에는 정책 작성의 마지막 조각, "JMESPath의 기초와 정책 내 데이터 추출 원리"를 통해 변수를 더 강력하게 가공하는 법을 알아보겠습니다. 궁금한 점은 언제든 댓글로 남겨주세요! 😊

---