[Kyverno] Policy(네임스페이스 단위) vs ClusterPolicy(클러스터 전체)의 차이

안녕하세요! 쿠버네티스 보안 정책의 마술사, Kyverno 시리즈 세 번째 시간입니다. 🧙‍♂️

지난 시간까지 우리는 Kyverno를 튼튼하게 설치하고 최적화하는 방법을 배웠습니다. 이제 본격적으로 정책(Policy)을 만들어볼 차례인데요. Kyverno 정책을 만들려고 보면 가장 먼저 마주치는 선택지가 있습니다.

바로 "Policy로 만들 것인가, ClusterPolicy로 만들 것인가?" 입니다. 이 둘의 차이를 모르면 나중에 정책이 꼬이거나 관리 효율이 떨어질 수 있어요. 오늘 10분만 투자해서 이 개념을 완벽히 정리해 봅시다! 🚀

---

🏗️ 1. 범위(Scope)의 결정적 차이

가장 핵심적인 차이는 정책이 "어디까지 영향을 미치는가"입니다.

🔹 Policy (네임스페이스 단위)

• 정의: 특정 네임스페이스(Namespace) 안에 귀속되는 리소스입니다.
• 범위: 정책이 생성된 그 네임스페이스 안의 리소스들에만 영향을 미칩니다.
• 비유: 아파트 단지 내 '우리 집'에만 적용되는 가훈이나 규칙과 같습니다.

🔸 ClusterPolicy (클러스터 단위)

• 정의: 클러스터 전체 수준에서 정의되는 리소스입니다.
• 범위: 클러스터 내의 모든 네임스페이스에 걸쳐 리소스들을 감시하고 제어합니다.
• 비유: 아파트 단지 전체에 적용되는 '관리 규약'이나 모든 주민이 지켜야 할 공통 규칙입니다.

---

💻 2. 코드로 보는 차이점

YAML 구조를 보면 그 차이가 더 명확해집니다. kind와 metadata 부분을 주목해 보세요!

✅ Policy 예시 (특정 네임스페이스용)

이 정책은 staging 네임스페이스 안에서 생성되는 Pod들에 대해서만 레이블 검사를 수행합니다.

YAML

 

apiVersion: kyverno.io/v1
kind: Policy # <--- 그냥 Policy입니다.
metadata:
  name: check-team-label
  namespace: staging # <--- 특정 네임스페이스를 지정해야 합니다.
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-label
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "The label 'team' is required in staging namespace."
      pattern:
        metadata:
          labels:
            team: "?*"

✅ ClusterPolicy 예시 (전체 클러스터용)

이 정책은 클러스터 내의 어떤 네임스페이스든 상관없이 모든 Pod을 검사합니다.

YAML

 

apiVersion: kyverno.io/v1
kind: ClusterPolicy # <--- ClusterPolicy입니다.
metadata:
  name: disallow-root-user # <--- 네임스페이스 필드가 없습니다!
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-run-as-non-root
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Running as root is not allowed in this cluster."
      pattern:
        spec:
          securityContext:
            runAsNonRoot: true

---

⚖️ 3. 언제 무엇을 사용해야 할까요? (Use Cases)

선택의 기준은 '관리 주체'와 '적용 대상'입니다.

🙋‍♂️ Policy를 사용하는 경우 (팀 단위)

• 네임스페이스별 자율성: A팀은 Strict한 보안이 필요하고, B팀은 테스트를 위해 완화된 정책이 필요할 때.
• 권한 분리: 각 팀의 네임스페이스 관리자가 직접 본인 팀의 정책을 관리하고 싶을 때.
• 로컬 테스트: 특정 네임스페이스에서만 정책을 시범 적용해보고 싶을 때.

👮‍♂️ ClusterPolicy를 사용하는 경우 (전사 보안팀 단위)

• 전역 보안 표준: "어떤 팀이든 Root 계정 사용 금지", "이미지 태그에 latest 사용 금지" 등 전사 공통 규칙.
• 인프라 자동화: 네임스페이스가 생성될 때마다 공통적인 NetworkPolicy나 가이드를 자동으로 주입(Generate)하고 싶을 때.
• 중앙 집중 관리: 관리자가 한 곳에서 모든 정책을 제어하고 클러스터 전체의 준수 상태를 보고받고 싶을 때.

---

📊 4. 한 눈에 비교하는 요약표

구분	Policy	ClusterPolicy
API Kind	Policy	ClusterPolicy
리소스 범위	Namespace-scoped	Cluster-scoped
대상 범위	특정 네임스페이스 내부	클러스터 전체 네임스페이스
관리 권한	네임스페이스 관리자 가능	클러스터 관리자 전용
사용 사례	팀별 커스텀 규칙, 로컬 테스트	전사 보안 가이드라인, PSS 준수

---

💡 운영자를 위한 실무 팁 (Best Practices)

1. 기본은 ClusterPolicy: 대부분의 보안 정책(Best Practices)은 클러스터 전체에 일관되게 적용되는 것이 좋으므로 ClusterPolicy를 우선적으로 고려하세요.
2. 이름 중복 주의: Policy와 ClusterPolicy의 이름이 같더라도 리소스 종류가 다르기 때문에 공존할 수 있습니다. 하지만 혼동을 피하기 위해 명확한 네이밍 규칙(ex: cp- 접두사 등)을 정하는 것이 좋습니다.
3. 보고서 확인: ClusterPolicy의 위반 사항은 ClusterPolicyReport에 기록되고, Policy의 위반 사항은 해당 네임스페이스의 PolicyReport에 기록됩니다.

---

🌟 마치며

오늘은 Kyverno 정책의 두 가지 큰 줄기인 Policy와 ClusterPolicy의 차이점을 딥다이브 해보았습니다.

이 개념을 명확히 잡으셨다면, 이제 여러분은 "어떤 정책을 어디에 배치해야 효율적인가"에 대한 전략을 세울 수 있는 준비가 되신 겁니다! 👏

다음 시간에는 정책 작성의 꽃, "Match와 Exclude 블록을 활용한 정교한 리소스 선택법"에 대해 다뤄보겠습니다. 궁금한 점은 언제든 댓글로 남겨주세요! 😊

---