💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — "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:

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:

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:

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:

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:

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:

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:

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 | 알려진 권한 상승을 차단. 일반 워크로드 |

| restricted | hardened, PSS 표준의 가장 엄격 |

PSA 의 세 가지 mode.

- **enforce** — 위반 시 차단.

- **audit** — audit log 에만 기록.

- **warn** — kubectl 에 경고만.

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

apiVersion: v1

kind: Namespace

metadata:

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:

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:

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:

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:

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)](https://www.cncf.io/announcements/2024/11/12/cloud-native-computing-foundation-announces-the-graduation-of-kyverno/)

- [Kyverno Documentation](https://kyverno.io/docs/)

- [Kyverno Policies Library](https://kyverno.io/policies/)

- [Kyverno GitHub — kyverno/kyverno](https://github.com/kyverno/kyverno)

- [OPA Gatekeeper Documentation](https://open-policy-agent.github.io/gatekeeper/website/docs/)

- [Open Policy Agent](https://www.openpolicyagent.org/)

- [Rego Language Reference](https://www.openpolicyagent.org/docs/latest/policy-language/)

- [Kubernetes 1.30 release notes — VAP GA](https://kubernetes.io/blog/2024/04/17/kubernetes-v1-30-release/)

- [Validating Admission Policy Documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)

- [Kubernetes 1.32 — Mutating Admission Policy alpha](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/)

- [Mutating Admission Policy Documentation](https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/)

- [Pod Security Admission Documentation](https://kubernetes.io/docs/concepts/security/pod-security-admission/)

- [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)

- [CEL — Common Expression Language](https://github.com/google/cel-spec)

- [Cedar Policy Language](https://www.cedarpolicy.com/)

- [Falco — CNCF Graduated](https://falco.org/)

- [Falco GitHub — falcosecurity/falco](https://github.com/falcosecurity/falco)

- [Falcosidekick](https://github.com/falcosecurity/falcosidekick)

- [KubeArmor Documentation](https://kubearmor.io/)

- [KubeArmor GitHub — kubearmor/KubeArmor](https://github.com/kubearmor/KubeArmor)

- [Cilium Tetragon](https://tetragon.io/)

- [Tetragon GitHub — cilium/tetragon](https://github.com/cilium/tetragon)

- [Sigstore Project](https://www.sigstore.dev/)

- [Cosign Documentation](https://docs.sigstore.dev/cosign/overview/)

- [Sigstore Policy Controller](https://docs.sigstore.dev/policy-controller/overview/)

- [Connaisseur GitHub — sse-secure-systems/connaisseur](https://github.com/sse-secure-systems/connaisseur)

- [Trivy Documentation](https://aquasecurity.github.io/trivy/)

- [Trivy Operator](https://aquasecurity.github.io/trivy-operator/)

- [Polaris (Fairwinds)](https://polaris.docs.fairwinds.com/)

- [Goldilocks (Fairwinds)](https://goldilocks.docs.fairwinds.com/)

- [Kubescape (ARMO)](https://kubescape.io/)

- [ARMO Platform](https://www.armosec.io/)

- [kube-bench](https://github.com/aquasecurity/kube-bench)

- [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes)

- [kube-hunter](https://github.com/aquasecurity/kube-hunter)

- [kube-score](https://kube-score.com/)

- [Checkov](https://www.checkov.io/)

- [Datree sunset announcement (2023)](https://www.datree.io/)

- [Toss SLASH conference](https://toss.tech/slash)

- [if(kakao) developers conference](https://if.kakao.com/)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/blog/)

- [NSA-CISA Kubernetes Hardening Guidance](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-238a)

- [SLSA Framework](https://slsa.dev/)