본문 바로가기
클라우드/Kyverno

Kyverno 마스터 클래스: 패턴 매칭으로 완성하는 선언적 쿠버네티스 보안 가이드

by gasbugs 2026. 1. 6.

안녕하세요! 쿠버네티스 보안의 강력한 방어막, Kyverno 마스터 시리즈의 일곱 번째 시간입니다. 🛡️

지난 시간까지 우리는 정책의 두뇌라고 할 수 있는 변수와 JMESPath를 배웠습니다. 이제 그 지식을 바탕으로 실제로 리소스를 검증하고 차단하는 실전 방어 기술을 배워볼 차례입니다.

오늘 다룰 내용은 Kyverno의 꽃이라 불리는 validate 규칙과 정책 운영의 핵심 전략인 failurePolicy, validationFailureAction입니다. 딥다이브하며 클러스터 보안 전문가로 거듭나 봅시다! 🚀


🏗️ 1. validate 규칙의 기본 구조와 패턴 매칭

validate 규칙은 사용자가 생성하려는 리소스가 우리가 정의한 '패턴'에 맞는지 확인하는 과정입니다.

🔹 기본 구조

가장 단순한 형태의 validate 정책은 리소스의 특정 필드값이 우리가 원하는 값인지 확인합니다.

YAML
validate:
  message: "이유를 설명하는 메시지 (사용자에게 노출됨)"
  pattern:
    spec:
      containers:
      - name: "*" # 모든 컨테이너에 대해
        securityContext:
          allowPrivilegeEscalation: false # 이 값이 반드시 false여야 함

🔸 패턴 매칭(Pattern Matching)의 마법

Kyverno의 패턴 매칭은 매우 직관적입니다. 리소스의 YAML 구조를 그대로 따라가면서 값을 비교하죠.

  • 와일드카드 (*): 0개 이상의 문자와 매칭됩니다. (예: image: "nginx:*"는 모든 nginx 버전을 허용)
  • 물음표 (?): 단 하나의 문자와 매칭됩니다.
  • 비어있지 않음 (?*): 해당 필드가 반드시 존재하고 값이 비어있지 않아야 함을 의미합니다.
  • 조건부 매칭: 숫자나 문자열에 대해 >, <, >= 등의 연산자를 사용할 수 있습니다.

🚦 2. failurePolicy: Webhook 연결 실패 시 당신의 선택은?

쿠버네티스 API 서버와 Kyverno 사이의 통신에 문제가 생겼을 때(네트워크 장애, Kyverno Pod 다운 등) 클러스터가 어떻게 반응해야 할지를 결정하는 매우 중요한 설정입니다.

🟢 Ignore (기본값)

  • 작동 방식: Kyverno가 응답하지 않으면 "어쩔 수 없지" 하고 리소스 생성을 허용합니다.
  • 장점: Kyverno 장애가 전체 서비스 배포 장애로 이어지지 않습니다. (가용성 우선)
  • 단점: 보안 검사 없이 위험한 리소스가 배포될 수 있습니다.

🔴 Fail

  • 작동 방식: Kyverno가 응답하지 않으면 "위험하니까 일단 멈춰!" 하고 리소스 생성을 차단합니다.
  • 장점: 보안을 철저하게 유지할 수 있습니다. (보안 우선)
  • 단점: Kyverno에 문제가 생기면 클러스터 내의 모든 리소스 생성/수정 작업이 마비됩니다.

💡 전문가의 팁: 운영 환경에서는 Ignore를 기본으로 하되, Kyverno를 고가용성(HA)으로 구성하여 장애 확률을 낮추는 것이 일반적인 전략입니다.


⚖️ 3. validationFailureAction: Audit(관조) vs Enforce(강제)

정책을 위반했을 때 Kyverno가 어떤 액션을 취할지 결정합니다. 이는 정책의 '모드'라고 이해하면 쉽습니다.

👁️ Audit (모니터링 모드)

  • 동작: 리소스 생성을 허용하되, 위반 사항을 PolicyReport에 기록합니다.
  • 용도: 새로운 정책을 처음 도입할 때, 기존 서비스들에 어떤 영향을 줄지 파악하기 위해 사용합니다. (Dry-run과 유사)

🚫 Enforce (차단 모드)

  • 동작: 정책을 위반한 리소스 생성을 즉시 차단하고 사용자에게 에러 메시지를 보냅니다.
  • 용도: 이미 검증된 정책을 통해 클러스터 보안 가이드라인을 강력하게 강제할 때 사용합니다.

💻 실전 종합 예제: 보안 강화 정책

위의 세 가지 핵심 개념을 모두 담은 실전 정책 코드를 살펴봅시다.

YAML
 
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-secure-defaults
spec:
  # 1. 정책 위반 시 즉시 차단 (운영 단계)
  validationFailureAction: Enforce 
  
  # 2. Kyverno 장애 시에도 API 서버는 일단 진행 (가용성 보장)
  # 참고: 이 설정은 실제 WebhookConfiguration에 반영됩니다.
  failurePolicy: Ignore 
  
  background: true
  rules:
  - name: check-image-registry
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "허용되지 않은 레지스트리에서 이미지를 가져올 수 없습니다. (우리 회사 전용 사용 필수)"
      pattern:
        spec:
          containers:
          - image: "my-company.registry.io/*" # 패턴 매칭 활용

🚀 운영자를 위한 전략적 전환 가이드

새로운 보안 정책을 클러스터에 배포할 때는 다음과 같은 단계를 밟는 것이 가장 안전합니다.

  1. 1단계 (Audit 모드): validationFailureAction: Audit으로 배포합니다. 며칠간 PolicyReport를 보며 어떤 팀의 어떤 리소스가 걸리는지 확인합니다.
  2. 2단계 (공지 및 수정): 위반 리포트를 바탕으로 관련 팀에 연락하여 리소스 수정을 요청합니다.
  3. 3단계 (Enforce 전환): 모든 리소스가 준비되었을 때 Enforce로 전환하여 보안을 확립합니다.

🌟 마치며

오늘은 Kyverno 정책의 핵심 방어 기제인 validate와 운영 전략 설정들을 살펴보았습니다.

  • pattern으로 꼼꼼하게 검사하고,
  • failurePolicy로 장애 상황에 대비하며,
  • validationFailureAction으로 부드럽게 혹은 강력하게 보안을 적용하는 법을 익히셨습니다. 🛠️

이제 여러분은 단순히 정책을 만드는 것을 넘어, 실제 서비스 환경에 안전하게 정책을 안착시키는 법을 아는 숙련된 운영자가 되셨습니다! 💪 궁금한 점은 언제든 댓글로 남겨주세요! 😊