LabHub

블로그

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

2026-05-16 · 35 분 읽기 · #kubernetes#security#admission-controller#kyverno#opa-gatekeeper#rego#cedar#validating-admission-policy#cel#pod-security-admission#falco#kubearmor#cilium-tetragon#ebpf#sigstore#cosign#connaisseur#trivy-operator#polaris#goldilocks#kubescape#armo#kube-bench#kube-hunter#checkov#deep-dive

한국어English日本語

프롤로그 — "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 의 문제를 풀고 있는가" 부터 알아야 한다.

레이어시점대표 도구주요 질문
Admission (정책 게이트)API server 요청 시Kyverno, OPA Gatekeeper, VAP, MAP, PSA"이 매니페스트를 admit 할까?"
Runtime (실행 시)container 실행 후Falco, KubeArmor, Tetragon"이 프로세스/syscall 이 정상인가?"
Image / Supply chain빌드 → 배포Sigstore Policy Controller, Connaisseur, Trivy Operator"이 이미지 믿어도 되나?"
Posture / Audit주기적 평가Kubescape, kube-bench, Polaris, Checkov"내 클러스터가 안전한 상태인가?"

오해 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 은 다음 형태로 수렴한다.

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

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 의 강점.

약점.

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 의 강점.

약점.

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 됐다. 의미가 크다.

가장 단순한 예 — 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 의 강점.

약점.

권장 패턴: 단순한 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.

profile설명
privileged제한 없음. 시스템 워크로드용
baseline알려진 권한 상승을 차단. 일반 워크로드
restrictedhardened, PSS 표준의 가장 엄격

PSA 의 세 가지 mode.

전형적 운영: 신규 네임스페이스는 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 — 정책 언어 비교

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

언어출신패러다임강점약점
RegoOPA (CNCF)declarative, datalog 계열표현력, 범용성 (K8s 외 Envoy/TF)가파른 러닝커브
CELGoogletyped expression, eager evallightweight, latency 짧음, K8s 빌트인mutate 표현이 길어짐, cross-resource 제한
CedarAWS (2023 공개)typed, formally verified, ABAC정형 분석 가능, IAM-스타일K8s 통합 아직 thin
Kyverno YAMLNirmata → CNCF매니페스트 자체가 정책진입장벽 가장 낮음표현력 한계

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 은 아니다.

실무 권장.

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 에서).

운영 관점.

약점.

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 의 강점.

약점.

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

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

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

Tetragon 의 차별점.

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 은.

약점.

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

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

Sigstore 생태계.

가장 단순한 흐름.

# 빌드 머신에서 (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 정책에 다시 활용할 수 있다.

스캔 대상.

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
# ...

특징.

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"
# ...

권장 사용처.

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

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

토스 (Toss)

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

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

카카오 (Kakao)

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

메르카리 (Mercari)

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

LINE / Yahoo Japan

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

공통 패턴

세 회사 모두 공통.

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

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

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

시나리오AdmissionRuntimeImagePosture
소규모 (10 노드 미만), 빠른 시작PSA + KyvernoFalcoTrivy CI 만kube-bench 분기별
중규모 prod (수십~수백 노드)PSA + Kyverno + VAPFalco + Tetragoncosign + Sigstore PCKubescape 월간
엔터프라이즈, 멀티 클러스터PSA + Kyverno + 사내 webhookFalco + KubeArmor or Tetragoncosign + Sigstore PC or ConnaisseurKubescape + kube-bench
금융/Regulated (PCI/HIPAA)PSA restricted + Kyverno + OPAFalco + KubeArmorConnaisseur (멀티 백엔드)Kubescape + kube-bench + Checkov
OPA/Rego 자산 많음OPA Gatekeeper 유지 + VAP 단순 룰Falcocosignkube-bench
Cilium CNI 사용Kyverno or VAPTetragoncosignKubescape

운영 관점에서 잊지 말 것.

에필로그 — 보안은 도구가 아니라 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

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-kubernetes-admission-policies-security-2026-kyverno-opa-gatekeeper-vap-falco-kubearmor-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다