Kubernetes admission policies & 보안 2026 — Kyverno (CNCF Graduated) / OPA Gatekeeper / VAP (CEL) / Falco / KubeArmor / Tetragon 심층 가이드

프롤로그 — "admission 컨트롤러 하나만 켜면 다 막힌다"는 신화

2026년 어느 보안 검토 회의.

신입 SRE: "Pod Security Admission 켰는데 왜 또 Kyverno 가 필요해요?" 시니어 보안 엔지니어: "PSA 는 pod 5개 필드만 본다. registry 강제, label 강제, mutate 는 PSA 가 못해." 신입: "그럼 OPA Gatekeeper 로 다 하면 안 돼요?" 시니어: "Rego 배워서 운영할 사람 있어?" 신입: "그럼 그냥 새로 나온 Validating Admission Policy 쓰면…" 시니어: "그게 CEL 이라 image registry mutate 는 못해. 우리 결제 클러스터엔 mutate 가 필요해."

이 짧은 대화가 2026년 K8s 보안의 본질이다. 단일 도구로 모든 보안 요구를 만족시키는 시대는 끝났다. admit 단계는 admit 단계대로, 런타임은 런타임대로, 이미지는 이미지대로 — 각자 다른 도구가 다른 layer 에서 동작한다.

이 글은 그 전체 지형을 한 번에 정리한다. CNCF Graduated 된 Kyverno (2024.11), Rego 기반 OPA Gatekeeper, k8s 1.30 GA 된 빌트인 VAP (2024.4), 1.32 alpha 의 MAP, PSP 를 대체한 PSA, 런타임 보안의 Falco / KubeArmor / Tetragon, 이미지 서명의 Sigstore / Connaisseur, 스캐닝의 Trivy Operator, 자세 평가의 Kubescape / kube-bench / kube-score, 그리고 한국·일본 빅테크가 무엇을 어떻게 쓰는지까지.

1장 · 2026년 K8s admission & 보안 지도 — 4 개의 레이어로 갈라진다

먼저 큰 그림. 2026년 쿠버네티스 보안은 4 개의 layer 로 나뉜다. 도구를 고르기 전에 "내가 어떤 layer 의 문제를 풀고 있는가" 부터 알아야 한다.

오해 1: "Kyverno 로 다 된다" — 런타임은 못 막는다. shell 이 컨테이너 안에서 curl evil.com 호출하는 건 admission 이 못 본다. 오해 2: "Falco 가 있으면 안전하다" — admit 안 막으면 너무 늦다. privileged pod 가 이미 떠 있으면 Falco 는 알람만 띄울 뿐. 오해 3: "PSA 가 PSP 후속이니 PSA 만 쓰면 된다" — PSA 는 ~5개 baseline/restricted 필드만 본다. registry 강제, label 강제는 PSA 가 못한다.

2026년의 표준 stack 은 다음 형태로 수렴한다.

• Admission: PSA (baseline/restricted) + Kyverno or VAP (mutate 가 필요하면 Kyverno, 단순 validate 만이면 VAP)
• Runtime: Falco (널리 채택) + Tetragon (eBPF 정밀도가 필요하면)
• Image: Sigstore + Cosign (signed image 강제) + Trivy Operator (CVE 스캔)
• Posture: Kubescape or kube-bench (월 1회 이상 audit)

이제 각 도구를 하나씩 본다.

2장 · Kyverno — CNCF Graduated (2024.11), YAML 기반 정책

Kyverno 는 2024년 11월에 CNCF 의 Graduated 프로젝트로 승격됐다. Linkerd, Argo, Cilium 같은 1군 졸업 프로젝트의 반열에 들어갔다는 뜻이다.

Kyverno 가 다른 admission 컨트롤러와 결정적으로 다른 점: 정책을 별도 DSL 이 아닌 쿠버네티스 매니페스트(YAML) 로 작성한다. Rego (OPA) 나 CEL (VAP) 같은 새 언어를 배울 필요가 없다. 이미 K8s 매니페스트를 쓰는 사람이라면 30분이면 첫 정책을 쓴다.

대표 예: 모든 Pod 에 team 라벨 강제.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Pod 는 반드시 'team' 라벨이 있어야 한다"
        pattern:
          metadata:
            labels:
              team: "?*"

Kyverno 의 3 가지 action.

1. validate — 검사만, admit 차단.
2. mutate — 매니페스트를 admit 전에 수정 (예: 기본 라벨/리소스 limit 자동 주입).
3. generate — 다른 리소스 자동 생성 (Namespace 생성 시 NetworkPolicy 자동 생성).

특히 mutate + generate 는 OPA Gatekeeper 가 오래 못 했던 영역이라 Kyverno 가 강세를 가진 지점. registry 자동 변경, ConfigMap 자동 배포, NetworkPolicy 자동 생성 등.

# 이미지 registry 강제 mutate
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: rewrite-image-registry
spec:
  rules:
    - name: replace-dockerhub
      match:
        any:
          - resources:
              kinds: ["Pod"]
      mutate:
        foreach:
          - list: "request.object.spec.containers"
            patchStrategicMerge:
              spec:
                containers:
                  - name: "{{ element.name }}"
                    image: "{{ regex_replace_all('^docker.io/', element.image, 'mirror.corp.local/dockerhub/') }}"

운영 관점에서 Kyverno 의 강점.

• policy report: 정책 위반을 K8s native 리소스 (PolicyReport) 로 기록. Grafana 대시보드, kubectl 로 바로 본다.
• CLI: kyverno apply policy.yaml --resource pod.yaml 로 클러스터 없이 정책 검증.
• policy library: kyverno.io/policies 에 100+ 검증된 정책 (CIS, NIST, PSS baseline/restricted 등).
• autogen: Deployment 정책을 쓰면 ReplicaSet/Pod 정책을 자동 생성.

약점.

• 복잡한 cross-resource 정책은 Rego 보다 표현력이 약하다 (Kyverno 1.10+ 의 CEL 통합으로 일부 해소).
• mutate 정책이 많아지면 admission latency 가 누적된다 (각 webhook 호출 50~200ms).

2026년 현재 Kyverno 는 OPA Gatekeeper 를 점유율로 추월했다는 보고가 다수. CNCF 설문에서 "사용 중인 admission policy 도구" 1위.

3장 · OPA Gatekeeper — Rego 기반, Kyverno 이전의 표준

Open Policy Agent (OPA) 는 2017년 Styra 가 만든 범용 정책 엔진. 쿠버네티스에 한정되지 않고 Envoy, Terraform, CI 까지 동일한 Rego 언어로 정책을 쓸 수 있다는 것이 큰 장점. Gatekeeper 는 그 OPA 를 K8s admission webhook 에 래핑한 컴포넌트.

Gatekeeper 의 핵심 개념 2개.

1. ConstraintTemplate — Rego 로 작성한 정책 로직 (재사용 가능한 템플릿).
2. Constraint — 그 템플릿의 인스턴스 (구체 파라미터 + 적용 범위).

ConstraintTemplate 예 — pod 에 특정 label 이 있어야 한다.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          required := input.parameters.labels
          provided := input.review.object.metadata.labels
          missing := required[_]
          not provided[missing]
          msg := sprintf("Missing required label: %v", [missing])
        }

그리고 그 템플릿의 Constraint.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: pods-must-have-team
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    labels: ["team", "owner"]

Rego 의 강점.

• 선언적, 비절차적. 한 줄에 cross-resource 조건 (예: "같은 namespace 에 ServiceAccount 가 있으면서 RoleBinding 도 있어야 한다") 도 쉽게.
• set/array 연산이 매우 강력. JSON 깊은 구조 검증에 최적.
• OPA 자체가 K8s 외부에서도 쓰인다. CI 의 Terraform plan 검증, Envoy 에서의 L7 인가 결정 등.

약점.

• 러닝커브가 진짜 가파르다. 익숙해지는 데 몇 주.
• ConstraintTemplate / Constraint 두 단계 구조가 매니페스트 작성을 길게 만든다.
• mutate 가 별도 컴포넌트 (Gatekeeper Mutation, beta). 한 도구로 끝나지 않는다.
• 정책 결과를 K8s native 리소스로 보기가 Kyverno 보다 어색 (audit log 위주).

2026년 현재 Gatekeeper 는 이미 OPA Rego 자산이 많은 조직, Envoy / Terraform 까지 통합 정책을 운영하려는 조직에서 유지된다. 신규 채택은 Kyverno 와 VAP 에 밀린다.

4장 · Validating Admission Policy (VAP) — k8s 1.30 GA (2024.4), 빌트인 CEL

2024년 4월 Kubernetes 1.30 에서 Validating Admission Policy (VAP) 가 GA 됐다. 의미가 크다.

• 빌트인. 별도 webhook 컴포넌트 설치 불필요. kube-apiserver 가 직접 평가.
• CEL (Common Expression Language) 기반. Google 이 만든 lightweight 표현식 언어, gRPC/Envoy/IAM 등에서도 사용.
• webhook 호출 비용 0. admission latency 가 외부 webhook 보다 훨씬 짧다.

가장 단순한 예 — Deployment 의 replicas 가 5 미만이면 거부.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deployment-replica-limit
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: "object.spec.replicas >= 5"
      message: "Deployment 는 최소 5 replicas 가 필요합니다"

그리고 ValidatingAdmissionPolicyBinding 으로 어디에 적용할지 정의.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: deployment-replica-limit-binding
spec:
  policyName: deployment-replica-limit
  validationActions: ["Deny"]
  matchResources:
    namespaceSelector:
      matchLabels:
        env: production

CEL 의 표현력은 점점 늘고 있다. 1.30 에서 GA 됐을 때는 단순 비교가 한계였지만, 1.31~1.32 에서 cross-resource lookup (paramRef, variables), authorizer check, namespace metadata 참조까지 가능해졌다.

# 좀 더 복잡한 예 — 컨테이너 이미지가 회사 registry 에서 와야 한다
validations:
  - expression: |
      object.spec.containers.all(c, c.image.startsWith('registry.corp.local/'))
    message: "이미지는 registry.corp.local/ 에서 와야 합니다"

VAP 의 강점.

• 빌트인, 의존성 0.
• 정책이 K8s 리소스. GitOps 친화적.
• CEL 평가가 in-process 라 latency 작음.
• failurePolicy/auditAnnotations/warnings 등 K8s native semantics.

약점.

• validate only. mutate 못함 (그건 MAP 의 영역, 다음 장).
• cross-resource lookup 이 Rego 보다 제한적.
• CEL 도 결국 새 언어. Kyverno 만큼 진입장벽이 낮지는 않다.
• 정책 라이브러리/생태계가 Kyverno 보다 얕다 (2026 기준).

권장 패턴: 단순한 validate (라벨/필드 확인, 단순 비교) 는 VAP, 복잡한 cross-resource + mutate 는 Kyverno. 한 클러스터에서 두 도구를 같이 쓰는 게 2026년의 표준이 되고 있다.

5장 · Mutating Admission Policy (MAP) — k8s 1.32 alpha (2024.12)

2024년 12월 Kubernetes 1.32 에서 Mutating Admission Policy (MAP) 가 alpha 로 들어왔다. VAP 의 mutate 형제. 아직 alpha 라 production 권장은 아니지만, 2026년 안에 beta/GA 될 가능성이 높다.

MAP 은 두 가지 mutate 방식을 제공한다.

1. ApplyConfiguration — server-side apply 의 typed configuration 객체를 CEL 로 만들어 머지.
2. JSON Patch — RFC 6902 JSON Patch 를 CEL 로 생성.

ApplyConfiguration 예 — 모든 Pod 에 기본 securityContext 강제.

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: default-security-context
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: |
          Object{
            spec: Object.spec{
              securityContext: Object.spec.securityContext{
                runAsNonRoot: true,
                seccompProfile: Object.spec.securityContext.seccompProfile{
                  type: "RuntimeDefault"
                }
              }
            }
          }

MAP 이 GA 되면 Kyverno 의 mutate 영역도 일부 빌트인으로 옮겨갈 가능성이 있다. 다만 Kyverno 의 generate, policy report, library 등은 여전히 차별점.

2026년 권장: MAP 은 1.33+ beta 안정화 까지는 시험용, 단순 default 주입 정도만 시범. 핵심 mutate 는 Kyverno 로.

6장 · Pod Security Admission (PSA) — PSP 를 대체한 빌트인

Pod Security Policy (PSP) 는 1.21 에서 deprecated, 1.25 에서 제거됐다. 그 자리를 Pod Security Admission (PSA) 가 채웠다. 1.23 에 베타, 1.25 부터 GA, 2026년 현재 거의 모든 클러스터에 기본 활성화.

PSA 의 세 가지 profile.

PSA 의 세 가지 mode.

• enforce — 위반 시 차단.
• audit — audit log 에만 기록.
• warn — kubectl 에 경고만.

전형적 운영: 신규 네임스페이스는 warn=restricted, audit=restricted, enforce=baseline 로 시작. 충분한 시간 후 enforce=restricted 로 강화.

apiVersion: v1
kind: Namespace
metadata:
  name: prod-payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

PSA 가 보는 필드는 좁다. hostPID, hostNetwork, privileged, runAsNonRoot, allowPrivilegeEscalation, seccompProfile, capabilities 등 PSS 의 잘 정의된 필드만. 즉 PSA 는 pod 보안의 floor 를 보장하고, registry 강제·라벨 강제·custom 정책은 Kyverno/VAP 가 위에서 추가한다.

2026년 합의: 모든 prod 네임스페이스 = PSA restricted enforce + Kyverno/VAP custom rules.

7장 · Rego vs CEL vs Cedar — 정책 언어 비교

정책 언어 자체를 한 번 비교하자. 도구를 선택하는 건 곧 언어를 선택하는 일이기 때문.

Rego 의 한 줄.

violation[msg] {
  input.review.object.kind == "Pod"
  some i
  not input.review.object.spec.containers[i].securityContext.runAsNonRoot
  msg := sprintf("Container %v must runAsNonRoot", [input.review.object.spec.containers[i].name])
}

같은 의도의 CEL.

object.spec.containers.exists(c, !c.securityContext.runAsNonRoot)

같은 의도의 Cedar (정책-자원 모델이 다르므로 직접 대응은 아님).

forbid (
  principal,
  action == K8s::Action::"CreatePod",
  resource is K8s::Pod
) when {
  resource.spec.containers.any(c, c.securityContext.runAsNonRoot == false)
};

Cedar 의 흥미로운 점은 정형 분석 (formal analysis) 가 가능하다는 것. 정책 두 개가 모순되는지, 어떤 입력이 허용되는지 등을 SMT solver 로 증명한다. AWS IAM 의 새 정책 언어로 채택됐고, 2026년에는 Cedar-K8s 통합 PoC 가 늘고 있지만 아직 mainstream 은 아니다.

실무 권장.

• Rego 자산이 이미 있다 / Envoy/TF 까지 통합: OPA Gatekeeper 유지.
• YAML 만으로 끝내고 싶다: Kyverno.
• 빌트인 + lightweight validate: VAP (CEL).
• AWS 중심 + 정책 정형성 중요: Cedar 를 K8s 외부에서 부분 도입.

8장 · Falco — CNCF Graduated, 런타임 보안의 표준

Falco 는 Sysdig 가 만든 런타임 보안 엔진으로, 2024년 CNCF Graduated 가 됐다. admission 이 막지 못한 모든 것 — 컨테이너 안에서 일어나는 syscall, file access, network IO — 를 본다.

Falco 의 동작 원리: 커널의 syscall 을 kprobe (또는 eBPF probe) 로 hook 해서 stream 으로 받고, Falco rule 로 매칭한다.

# falco_rules.yaml — shell 이 컨테이너 안에서 떴을 때 알람
- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: >
    Shell in container (user=%user.name container=%container.name
    image=%container.image.repository)
  priority: NOTICE
  tags: [shell, container]

priority 가 NOTICE/WARNING/ERROR/CRITICAL 등으로 나뉘고, output 은 stdout, syslog, gRPC, HTTP webhook, Slack, Loki 등으로 보낼 수 있다.

대표적 Falco 룰 (기본 룰셋 falco-rules 에서).

• "Write below etc" — /etc/ 아래에 쓰기 발생.
• "Read sensitive file untrusted" — /etc/shadow 같은 민감 파일 읽기.
• "Unexpected network outbound" — 컨테이너가 예상치 못한 외부 호스트로 connect.
• "Mining process detected" — 알려진 cryptominer 패턴.

운영 관점.

• Falcosidekick: Falco event 를 Slack, PagerDuty, Loki, S3 등 50+ destination 으로 fan-out 하는 사이드킥.
• Falco Talon: alarm → 자동 대응 (pod kill, network policy 적용 등).
• drift detection: container 이미지에 없던 새 바이너리가 컨테이너 안에서 실행되면 알람.

약점.

• 알람만, 차단 못한다 (Falco 자체는). Tetragon 이나 KubeArmor 와 달리 enforce 가 아닌 detect 위주.
• syscall 폭주하는 워크로드에서 부하 (eBPF driver 로 일부 완화).
• 룰 튜닝 없이는 false positive 가 많다 — 첫 2주는 알람의 90% 가 노이즈일 수 있다.

2026년 권장 stack: Falco (detect) + Tetragon/KubeArmor (enforce) + SIEM (Loki/Datadog) 로 fan-out.

9장 · KubeArmor — CNCF Sandbox, eBPF + LSM 기반 enforce

KubeArmor 는 Accuknox 가 주도하는 런타임 보안 도구로, CNCF Sandbox 단계. Falco 와 차별점은 detect 만이 아니라 enforce — eBPF 와 Linux Security Module (AppArmor, SELinux, BPF-LSM) 을 직접 활용해 syscall 자체를 차단할 수 있다.

KubeArmorPolicy 예 — 특정 워크로드에서 /etc/shadow 읽기 차단.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-shadow-read
  namespace: prod
spec:
  selector:
    matchLabels:
      app: payments
  file:
    matchPaths:
      - path: /etc/shadow
        readOnly: false
  action: Block

action: Audit / Block / Allow 의 3 모드. Block 은 kernel 단에서 막아 프로세스에 EPERM 반환.

KubeArmor 의 강점.

• enforce 가능. Falco 처럼 알람만 띄우는 게 아니라 실제 차단.
• LSM 기반이라 우회가 어렵다.
• per-pod policy. K8s 의 selector 로 워크로드별 다른 정책.
• policy discovery: 정상 동작을 학습해 policy 를 자동 제안하는 모드도 존재.

약점.

• Sandbox 라 생태계와 안정성은 Falco 보다 얇다.
• LSM (특히 BPF-LSM) 이 활성화된 커널 필요 (5.7+).
• 잘못된 정책이 합법 워크로드를 죽일 수 있다 — Audit 모드로 충분히 검증 후 Block.

권장 패턴: Falco 로 알람 → KubeArmor 로 enforce. 둘은 경쟁이 아니라 보완 관계.

10장 · Cilium Tetragon — eBPF 기반 관찰성 + 보안

Tetragon 은 Isovalent (Cilium 의 회사, 2023년 Cisco 인수) 가 만든 eBPF 기반 런타임 보안 & 관찰성 도구. Cilium 의 자매 프로젝트로 동일한 eBPF 인프라를 공유한다.

Tetragon 의 차별점.

• kernel hook 의 깊이. tracepoint, kprobe, uprobe 까지 polymorphic 하게 hook.
• process lineage. 모든 프로세스의 부모-자식 관계를 추적 — "이 cryptominer 는 어느 web 요청에서 시작됐는가" 를 답할 수 있다.
• enforce 가능. SIGKILL signal injection, override return value 로 syscall 차단.
• observability 가 일급. event 를 JSON 으로 stream — Grafana, ELK, Datadog 에 native 통합.

TracingPolicy 예 — 컨테이너 안에서 /etc/passwd 열기를 추적.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: watch-passwd-open
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Equal"
              values:
                - "/etc/passwd"
          matchActions:
            - action: Sigkill

이 정책은 /etc/passwd 가 open 되면 그 프로세스를 즉시 kill. Falco 의 detect 와 KubeArmor 의 enforce 를 한 도구에 합친 형태.

2026년 현재 Tetragon 은.

• Cilium 을 쓰는 곳에서 자연스럽게 같이 채택. CNI = Cilium 인 클러스터에서는 Tetragon 도입이 거의 무료.
• 고급 forensics. 사후 조사 시 process tree 가 추적 가능한 게 Falco 보다 강하다.
• Falco 와 함께 쓰는 경우도 많다. Falco 는 룰 라이브러리가 크고, Tetragon 은 더 깊은 hook.

약점.

• 학습 곡선이 Falco 보다 가파르다.
• Cilium 생태계를 안 쓰면 도입 동기 약함.

11장 · Sigstore Policy Controller + Connaisseur — 서명된 이미지 강제

이미지 공급망 보안의 핵심: 무엇이 클러스터에 들어오는가. 2026년의 표준은 두 가지 — Sigstore (Linux Foundation 산하) 의 cosign 서명, 그리고 그 서명을 K8s 에서 강제하는 admission 컨트롤러.

Sigstore 생태계.

• cosign — 컨테이너 이미지에 서명/검증하는 CLI.
• fulcio — short-lived 서명 인증서 발급 (CT log 기반).
• rekor — 모든 서명을 기록하는 transparency log (immutable).
• Sigstore Policy Controller — K8s admission 에서 cosign 서명을 검증.

가장 단순한 흐름.

# 빌드 머신에서 (CI)
cosign sign --yes ghcr.io/corp/api:v1.2.3

# 또는 keyless (OIDC 기반)
COSIGN_EXPERIMENTAL=1 cosign sign --yes \
  --identity-token=$(cat /var/run/secrets/tokens/oidc) \
  ghcr.io/corp/api:v1.2.3

검증 정책 (Sigstore Policy Controller).

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: signed-by-corp
spec:
  images:
    - glob: "ghcr.io/corp/**"
  authorities:
    - keyless:
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subject: "https://github.com/corp/.*"

이 정책이 적용된 네임스페이스에서는 GitHub Actions OIDC 토큰으로 서명된 이미지만 admit 된다. 키 관리 없이도 (keyless) 가능한 게 fulcio + rekor 의 마법.

Connaisseur (SAP 가 만든 오픈소스) 는 또 다른 옵션. 서명된 이미지 + Notary v1/v2 + cosign + Docker Content Trust 까지 멀티 백엔드를 지원. Sigstore Policy Controller 가 cosign-only 라면 Connaisseur 는 멀티 백엔드.

# Connaisseur config 일부
validators:
  - name: corp-cosign
    type: cosign
    trust_roots:
      - name: default
        key: |
          -----BEGIN PUBLIC KEY-----
          ...
          -----END PUBLIC KEY-----
policy:
  - pattern: "ghcr.io/corp/*:*"
    validator: corp-cosign

2026년 권장: OIDC keyless cosign + Sigstore Policy Controller 가 simplest. 멀티 백엔드 / regulated 환경은 Connaisseur.

12장 · Trivy Operator — 이미지 스캐닝의 K8s native 통합

Aqua Security 의 Trivy 는 OSS CVE 스캐너 중 가장 널리 쓰이는 도구. Trivy Operator 는 그 Trivy 를 K8s native 로 통합한 컨트롤러 — 클러스터의 모든 이미지/리소스를 주기적으로 스캔하고 결과를 K8s 리소스 (VulnerabilityReport, ConfigAuditReport, ExposedSecretReport 등) 로 기록한다.

# Trivy Operator 설치 후 자동 생성되는 VulnerabilityReport 예
apiVersion: aquasecurity.github.io/v1alpha1
kind: VulnerabilityReport
metadata:
  name: pod-api-deployment-565cd
  namespace: prod
report:
  artifact:
    repository: ghcr.io/corp/api
    tag: v1.2.3
  summary:
    criticalCount: 0
    highCount: 2
    mediumCount: 5
  vulnerabilities:
    - vulnerabilityID: CVE-2024-XXXXX
      severity: HIGH
      ...

이 리소스를 Grafana/Loki/Datadog 으로 보내거나, Kyverno 정책으로 "Critical CVE 가 있는 이미지는 거부" 같은 admit 정책에 다시 활용할 수 있다.

스캔 대상.

• 컨테이너 이미지 — 베이스 OS 패키지 + 언어 패키지 (npm, pip, go.mod, ...).
• K8s 리소스 misconfig — Trivy 자체의 K8s 검사 룰.
• secrets — 이미지나 매니페스트 안의 secret 노출.
• SBOM 생성 — CycloneDX, SPDX.

2026년 권장: CI 에서 빌드 시 Trivy scan + Trivy Operator 로 클러스터에서 지속 스캔 + Kyverno 로 Critical CVE 거부 의 3 단 방어.

13장 · Polaris / Goldilocks (Fairwinds) — 리소스 right-sizing

Fairwinds 의 두 오픈소스. 보안이라기보다 best practice 자동화에 가깝다.

Polaris 는 K8s 매니페스트의 best practice 위반을 보는 도구. CPU/메모리 limit 없음, runAsNonRoot 빠짐, latest 태그 사용 등 100+ 룰. admission webhook 모드, CI 모드, 대시보드 모드 3 가지.

# polaris config 일부
checks:
  cpuLimitsMissing: warning
  memoryLimitsMissing: warning
  runAsRootAllowed: danger
  hostIPCSet: danger
  notReadOnlyRootFilesystem: warning

Goldilocks 는 VerticalPodAutoscaler 의 recommendation 모드를 활용해 워크로드별 권장 request/limit 를 자동 계산해 대시보드로 보여준다. "이 deployment 는 CPU request 50m 으로 줄여도 된다" 같은 권고.

# Goldilocks 설치 (helm)
helm install goldilocks fairwinds-stable/goldilocks --namespace goldilocks
# 모니터링할 네임스페이스 라벨링
kubectl label ns prod goldilocks.fairwinds.com/enabled=true

둘 다 직접적 보안은 아니지만 misconfig 이 보안 사고의 60% 이상 이라는 통계를 생각하면 보안 stack 의 일부다.

14장 · Kubescape (ARMO) — 보안 자세 평가

Kubescape 는 ARMO 가 만든 (현재 CNCF Incubating, 2023년 승격) 보안 자세 평가 도구. NSA-CISA Kubernetes Hardening Guidance, MITRE ATT&CK, CIS Kubernetes Benchmark 등의 프레임워크로 클러스터를 평가한다.

# 클러스터를 NSA 프레임워크로 스캔
kubescape scan framework nsa

# 결과 예
# Control: C-0007 Data Destruction
# Resources: 23
# Compliance Score: 87.5%
# Failed: 3 resources
# ...

특징.

• 다양한 프레임워크 — NSA, MITRE, CIS, ArmoBest, AllControls.
• IDE 통합 — VS Code 확장으로 매니페스트 작성 중에도 평가.
• GitOps 친화적 — kubescape scan 을 CI 에 넣어 PR 단계에서 차단.
• 호스팅 SaaS (ARMO Platform) 와 OSS CLI 둘 다 존재.

Kubescape 가 다른 도구와 다른 점: end-to-end 평가. admission 만, 런타임만이 아니라 RBAC, network policy, image, configuration 까지 한 번에 본다.

# 단일 워크로드만 스캔
kubescape scan workload deployment/api -n prod

# YAML 파일 직접 스캔 (CI 용)
kubescape scan ./manifests/*.yaml

15장 · kube-bench / kube-hunter / kube-score / Checkov K8s — 보조 도구들

마지막으로 자주 같이 쓰는 보조 도구 4 개.

kube-bench (Aqua Security) — CIS Kubernetes Benchmark 을 실행한다. control plane 노드, etcd, kubelet, policies 까지 약 200 개 체크.

# kube-bench 를 노드에서 Job 으로 실행
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs -l job-name=kube-bench

# 예시 출력
# [PASS] 1.1.1 Ensure that the API server pod specification file ...
# [FAIL] 1.2.10 Ensure that the admission control plugin EventRateLimit is set
# ...

EKS/AKS/GKE 별 전용 변형도 있다 (eks-bench, etc.).

kube-hunter (Aqua) — 클러스터를 외부에서 (혹은 내부에서) 능동적으로 hunt 한다. pen-testing 도구. "이 etcd 가 인증 없이 노출돼 있다" 같은 active discovery.

kube-hunter --remote 10.0.0.1
# Hunters Active: 17
# Vulnerabilities found:
# 1) Pod Has Privileged Access in container some-pod
# ...

kube-score — 단순한 매니페스트 정적 분석. 점수를 매긴다.

kube-score score deployment.yaml
# apps/v1/Deployment my-app
#     [CRITICAL] Container Image Pull Policy
#       · my-app -> ImagePullPolicy is not set
#     [WARNING] Container Resources
#       · my-app -> CPU limit is not set

CI 에 넣기 쉬운 도구.

Checkov (Bridgecrew → Palo Alto) — IaC 정적 분석의 광역. Terraform, CloudFormation, K8s, Helm, Kustomize, Dockerfile 등. K8s 매니페스트도 800+ 정책으로 검사.

checkov -d ./manifests --framework kubernetes
# Passed checks: 145, Failed checks: 12
# CKV_K8S_8: "Liveness Probe Should be Configured"
# ...

권장 사용처.

• kube-bench: 클러스터 셋업 직후 한 번, 그리고 분기별.
• kube-hunter: 새 클러스터 도입 시 red team 식.
• kube-score: CI 의 매니페스트 PR 단계.
• Checkov: IaC 전반의 통합 게이트 (TF + K8s + Docker 까지).

16장 · 한국 / 일본 K8s 보안 — 토스 / 카카오 / 메르카리

마지막으로 한국·일본 빅테크가 K8s 보안을 어떻게 하고 있는가. (공개 컨퍼런스 발표·블로그 기준)

토스 (Toss)

토스는 결제 도메인 특성상 PCI-DSS 가 강하게 적용된다. K8s 보안 stack 은.

• PSA restricted enforce 가 모든 prod 네임스페이스 기본.
• Kyverno 다수 정책 — 이미지 registry 강제, label/owner 강제, NetworkPolicy 자동 생성.
• 사내 admission webhook — Kyverno 가 못 다루는 도메인 정책 (예: 결제 서비스의 specific 헬름 차트 검증) 은 자체 webhook.
• Falco + Loki + Grafana — 런타임 알람 stack.
• 이미지 서명 — 내부 CI 가 cosign 으로 서명, Sigstore Policy Controller 로 강제.
• Trivy Operator — 매일 CVE 스캔, 결과를 사내 보안 대시보드로 전송.

SLASH 등 토스 컨퍼런스에서 "Kyverno 마이그레이션", "PSA 적용기" 발표가 늘었다.

카카오 (Kakao)

카카오는 그룹사 단위로 K8s 가 분산돼 있어, 카카오엔터프라이즈가 만든 사내 플랫폼 (DKOS, Kubeflow 기반 등) 위주. 공개된 if(kakao) 발표에서.

• OPA Gatekeeper 가 여전히 많이 쓰인다 — 사내 Rego 자산이 많고, Envoy/IaC 까지 통합.
• Kyverno 신규 서비스에 도입 증가.
• Falco, kube-bench 도 표준.
• 카카오엔터의 일부 SaaS 는 Kubescape 로 정기 audit.

메르카리 (Mercari)

메르카리는 GCP 중심이지만 K8s 보안 stack 은 매우 진보적.

• Sigstore + cosign + Sigstore Policy Controller 를 일찍 도입. 메르카리 엔지니어링 블로그에 keyless signing 도입기 글이 있다.
• Kyverno 가 표준 admission. GKE 의 PSA 와 함께.
• Falco + GKE 의 Container Threat Detection 병행.
• Trivy 가 빌드/런타임 양쪽에서.

LINE / Yahoo Japan

라인은 글로벌 트래픽 특성상 자체 보안 플랫폼이 존재. K8s 부분만 보면 OPA 와 Kyverno 혼재, Falco 가 런타임. Yahoo Japan 도 비슷한 그림.

공통 패턴

세 회사 모두 공통.

• PSA 는 기본, 그 위에 Kyverno (또는 OPA) 로 custom.
• 런타임은 Falco 가 최다, Tetragon 은 Cilium CNI 쓰는 곳에서 같이.
• 이미지 서명은 cosign 으로 수렴 중.
• Trivy 가 CVE 표준.

2026년 한·일 시장 트렌드: 단일 도구로 통합 보다 layer 별 적정 도구 의 stack 구성이 표준이 되고 있다.

17장 · 누가 무엇을 골라야 하나 — 시나리오별 권장

마지막으로 한 페이지 결정표.

운영 관점에서 잊지 말 것.

• dry-run 부터. 새 정책은 enforce 가 아니라 audit/warn 모드로 1~2주.
• policy 도 코드. GitOps (Argo/Flux) 로 관리, PR review 의무화.
• 알람 fatigue 주의. Falco 룰을 처음부터 켜면 90% 가 노이즈. 일주일 튜닝 후 enforce.
• drift detection. 클러스터의 실제 정책 != Git 의 정책 이 되는 순간 보안은 무너진다.
• 이미지 서명은 supply chain 의 80%. SLSA framework 와 함께 보라.

에필로그 — 보안은 도구가 아니라 layer 의 합주다

2026년 K8s 보안의 진짜 교훈은 도구가 아니라 합주다. admission 이 막고, 런타임이 보고, 이미지가 검증되고, posture 가 주기적으로 평가된다. 어느 한 layer 만 켜면 어느 한 layer 가 비어 있다.

도구는 바뀐다. 5년 전엔 PSP 를 운영하던 사람이 오늘은 PSA + Kyverno + VAP 를 운영하고, 내년엔 MAP 까지 운영할 수 있다. 그러나 layer 의 의미를 이해한 팀은 도구를 바꿔도 살아남는다. 한 도구에 의존한 팀은 그 도구가 deprecated 되는 순간 (Datree 처럼 2023년 sunset) 무너진다.

다음 글 후보: Cosign 과 SLSA — 공급망 보안의 진짜 깊이, Kyverno 정책 라이브러리 100선 — production 그대로 쓰는 정책, Tetragon process tree forensics — 사후 조사로 cryptominer 추적하기.

"보안은 admission 만이 아니다. admission 만 켜면 admit 된 후의 모든 것이 무방비다."

— K8s admission policies & 보안 2026, 끝.

참고 / References

• Kyverno — CNCF Graduated announcement (Nov 2024)
• Kyverno Documentation
• Kyverno Policies Library
• Kyverno GitHub — kyverno/kyverno
• OPA Gatekeeper Documentation
• Open Policy Agent
• Rego Language Reference
• Kubernetes 1.30 release notes — VAP GA
• Validating Admission Policy Documentation
• Kubernetes 1.32 — Mutating Admission Policy alpha
• Mutating Admission Policy Documentation
• Pod Security Admission Documentation
• Pod Security Standards
• CEL — Common Expression Language
• Cedar Policy Language
• Falco — CNCF Graduated
• Falco GitHub — falcosecurity/falco
• Falcosidekick
• KubeArmor Documentation
• KubeArmor GitHub — kubearmor/KubeArmor
• Cilium Tetragon
• Tetragon GitHub — cilium/tetragon
• Sigstore Project
• Cosign Documentation
• Sigstore Policy Controller
• Connaisseur GitHub — sse-secure-systems/connaisseur
• Trivy Documentation
• Trivy Operator
• Polaris (Fairwinds)
• Goldilocks (Fairwinds)
• Kubescape (ARMO)
• ARMO Platform
• kube-bench
• CIS Kubernetes Benchmark
• kube-hunter
• kube-score
• Checkov
• Datree sunset announcement (2023)
• Toss SLASH conference
• if(kakao) developers conference
• Mercari Engineering Blog
• NSA-CISA Kubernetes Hardening Guidance
• SLSA Framework