Infrastructure, 껍데기 제거

01 · 냉정한 실체

04 · 내부 실행

fork/exec가 실행 문맥을 만들고, namespace가 보이는 식별자·mount·interface를 바꾸며, cgroup controller가 CPU time과 memory charge를 회계한다. DNS는 이름을 주소로 바꿀 뿐 route나 방화벽을 열지 않는다. Linux kernel cgroup v2Linux namespaces(7)IETF TCP RFC 9293

05 · MINIMUM VERTICAL SLICE

검증 범위: node scripts/p00-lab.mjs는 공통 관찰을 자동 검증한다. SIGKILL·CPU throttling·cgroup OOM·network namespace 격리는 node scripts/p00-lab.mjs --docker가 PASS일 때만 검증된 것이다.

node scripts/p00-lab.mjs
node scripts/p00-lab.mjs --docker

정상 출력 / 관찰

공통 검사는 PASS한다. Linux 경계는 환경에 따라 이유가 있는 SKIP이다. 명시적 Docker mode는 image가 없으면 먼저 build하며, engine/build가 없으면 FAIL한다. 성공하려면 graceful exit 0, forced exit 137, nr_throttled 증가, OOMKilled=true, 서로 다른 net namespace inode가 모두 필요하다.

06 · HARDEN — production 확장

timeout은 connect/read/write로 나누고, retry는 idempotent operation에만 budget을 둔다. CPU quota와 memory limit은 성능·OOM failure boundary다. Linux kernel cgroup v2Linux namespaces(7)IETF TCP RFC 9293

07 · 코드와 설정 해부

실제 파일

scripts/p00-lab.mjs가 child PID·signal·TCP listener·reserved .invalid lookup을 공통 경로로 실행한다. --docker는 image가 없으면 docker/Dockerfile api target을 build하고 --cpus 0.10, --memory 32m, --network none과 cgroup counter를 사용하며 각 container fixture를 finally에서 제거한다.

이 설정이 없으면

PID만 확인하면 listener·DNS·route 실패를 놓친다. Docker mode의 PASS 없이 CPU throttling, OOMKilled, network namespace 격리를 재현했다고 기록하면 안 된다.

08 · End-to-end trace

client syscall → DNS resolver → SYN/SYN-ACK → TLS handshake → HTTP bytes → server FD를 양방향으로 추적한다.

09 · BREAK IT — 실패 주입

DNS 이름을 고의로 틀린 뒤 NXDOMAIN과 connect timeout을 비교한다. 전자는 resolver, 후자는 route/firewall/listener 층이다.

↳ 관찰용 프로세스를 종료하고 namespace·temporary cgroup을 제거한다.

10 · 테스트

signal exit code, port bind 충돌, DNS negative lookup, CPU quota, memory OOM을 각각 별도 assertion으로 확인한다.

13 · 운영 산출물

증상 → DNS → route → TCP → TLS → HTTP → process 순서의 확인표와 saturation runbook을 유지한다.

14 · 완료 조건

15 · 자가시험

DNS 조회는 성공하지만 connect가 30초 뒤 timeout된다. 어느 세 층을 먼저 반증할 것인가?

01 · 냉정한 실체

04 · 내부 실행

runtime은 OCI config를 읽어 namespaces, mounts, capabilities, seccomp, cgroup을 구성한 뒤 rootfs 안의 argv를 exec한다. PID 1은 signal 전달과 orphan reap 책임이 달라진다. OCI Runtime SpecificationDocker container securityLinux namespaces(7)

05 · MINIMUM VERTICAL SLICE

검증 범위: docker/Dockerfile과 docs/VERIFICATION.md의 image UID/read-only 결과를 대조한다. 아래 명령의 새 실행 결과가 현재 host의 증거다.

docker build --target api --tag infrastructure-lab-api:dev --file docker/Dockerfile .
docker run --rm --network none --read-only --cap-drop=ALL --user 10001:10001 --entrypoint node infrastructure-lab-api:dev -e "const fs=require('fs');console.log({pid:process.pid,uid:process.getuid(),net:fs.readlinkSync('/proc/self/ns/net')})"

정상 출력 / 관찰

컨테이너 안에서 PID 1, UID 10001과 Linux network namespace inode가 출력된다. host inode 비교와 TERM drain은 별도 명령이 필요하다.

06 · HARDEN — production 확장

non-root, read-only root, tmpfs, no-new-privileges, default seccomp, capability drop, bounded resources, TERM drain을 함께 적용한다. OCI Runtime SpecificationDocker container securityLinux namespaces(7)

07 · 코드와 설정 해부

실제 파일

docker/Dockerfile의 runtime stage는 UID/GID 10001을 만들고 api/worker stage가 USER, HEALTHCHECK, node 직접 실행을 고정한다. 실행 명령의 read-only·cap-drop·network none은 서로 독립된 경계다.

이 설정이 없으면

USER만 두고 capability·seccomp·writable mount·signal을 생략하면 non-root여도 host kernel 공격면과 종료 중 data loss가 남는다.

08 · End-to-end trace

docker CLI → daemon/containerd → OCI runtime → clone/unshare/mount/cgroup → application PID 1을 추적한다.

09 · BREAK IT — 실패 주입

signal을 무시하는 PID 1 fixture를 실행해 grace period 이후 KILL과 미완료 작업을 관찰한다.

↳ container를 TERM으로 종료하고 orphan container와 volume을 확인한다.

10 · 테스트

UID, CapEff, writable paths, TERM latency, zombie 수, CPU/memory limit을 검사한다.

13 · 운영 산출물

PID 1, signal, OOM, filesystem permission, seccomp denial을 분리한 container runbook을 둔다.

14 · 완료 조건

15 · 자가시험

non-root container가 host kernel syscall 취약점으로 탈출할 수 있는 이유는?

01 · 냉정한 실체

04 · 내부 실행

BuildKit은 context와 instruction input을 해시해 cache를 선택한다. multi-stage COPY는 build toolchain을 runtime layer에서 제거하지만 copied artifact의 취약점까지 제거하지는 않는다. Docker multi-stage buildsOCI Image Specification v1.1.1SLSA specification

05 · MINIMUM VERTICAL SLICE

검증 범위: docker/Dockerfile과 docs/VERIFICATION.md의 최종 image UID, SBOM, 0 HIGH/CRITICAL 재검증 범위를 연결한다.

docker build --target api -t infrastructure-lab-api:dev -f docker/Dockerfile .
docker image inspect infrastructure-lab-api:dev

정상 출력 / 관찰

multi-stage image, UID 10001, pinned base, HEALTHCHECK, runtime에 dev dependency 부재가 확인된다.

06 · HARDEN — production 확장

dependency lock, base digest update 정책, build secret mount, provenance, SBOM, multi-arch builder와 재현성 범위를 기록한다. Docker multi-stage buildsOCI Image Specification v1.1.1SLSA specification

07 · 코드와 설정 해부

실제 파일

Dockerfile은 api-build/worker-build에서 lockfile install·compile·prune 후 runtime stage로 dist와 production dependencies만 COPY한다. base digest, USER 10001, HEALTHCHECK와 CMD가 runtime config를 결정한다.

이 설정이 없으면

lockfile보다 source를 먼저 COPY하면 cache가 깨지고, base digest·USER·healthcheck·secret mount를 생략하면 재현성·권한·상태 판정·credential 경계가 약해진다.

08 · End-to-end trace

source commit → context hash → layer blob → OCI manifest → registry digest → runtime rootfs를 연결한다.

09 · BREAK IT — 실패 주입

package manifest보다 source COPY를 먼저 두어 cache를 깨고 build time 차이를 측정한 뒤 순서를 고친다.

↳ dangling build cache를 측정한 뒤 필요할 때만 prune한다.

10 · 테스트

Dockerfile lint, secret scan, SBOM, vulnerability triage, non-root run, read-only run, TERM test를 분리한다.

13 · 운영 산출물

digest, source commit, SBOM, scan exception owner·expiry를 release record로 묶는다.

14 · 완료 조건

15 · 자가시험

취약한 base tag를 새 digest로 교체했는데 application digest가 왜 바뀌어야 하는가?

01 · 냉정한 실체

04 · 내부 실행

Compose는 network와 DNS alias를 만들고 dependency 조건에 따라 create/start 순서를 조정한다. application-level retry와 schema compatibility는 여전히 앱 책임이다. Docker Compose startup orderDocker container security

05 · MINIMUM VERTICAL SLICE

검증 범위: tests/integration과 docs/VERIFICATION.md의 실제 API→outbox→Redis→worker, retry, queue bound, TERM drain 결과가 근거다.

node scripts/verify-runtime.mjs --compose

정상 출력 / 관찰

migration 0, API/worker healthy, job 완료, bounded queue rejection, retry 3회, graceful drain이 통과한다.

06 · HARDEN — production 확장

Compose는 개발 parity 도구이지 multi-host scheduler가 아니다. production rollout, secret manager, HA database를 대신하지 않는다. Docker Compose startup orderDocker container security

07 · 코드와 설정 해부

실제 파일

compose/compose.yaml은 migration 완료와 PostgreSQL/Redis health를 API·worker startup gate로 연결하고 named volume·loopback port·resource bound를 선언한다. verify-runtime이 build부터 teardown까지 소유한다.

이 설정이 없으면

health condition이나 migration gate가 없으면 process start와 schema readiness가 뒤섞이고, volume/port teardown이 없으면 다음 실습이 stale state와 충돌한다.

08 · End-to-end trace

API transaction/outbox → Redis stream → worker claim → PostgreSQL status update를 trace ID로 연결한다.

09 · BREAK IT — 실패 주입

DB health delay, port conflict, stale volume, migration checksum mismatch를 fixture로 주입하고 각 health/log 차이를 본다.

↳ docker compose down --volumes로 상태 삭제 여부를 명시적으로 선택한다.

10 · 테스트

unit 뒤 실제 Compose integration, queue bound, failure retry, TERM drain을 수행한다.

13 · 운영 산출물

startup-order, migration, volume ownership, port collision runbook과 clean teardown 명령을 둔다.

14 · 완료 조건

15 · 자가시험

DB healthcheck가 통과한 직후 첫 query가 실패할 수 있는 두 이유는?

01 · 냉정한 실체

04 · 내부 실행

client는 manifest를 resolve하고 필요한 blob을 content digest로 pull한다. promotion은 동일 digest에 환경 metadata를 연결해야지 source를 다시 build하면 안 된다. OCI Distribution SpecificationSigstore documentationSLSA specificationGitHub Actions security hardening

05 · MINIMUM VERTICAL SLICE

검증 범위: github/actions-lock.json, container/release workflow와 docs/VERIFICATION.md의 local SBOM·scan 결과를 비교한다. GitHub-hosted provenance와 registry promotion은 미검증이다.

docker image inspect --format '{{.Id}} {{json .RepoDigests}}' infrastructure-lab-api:dev

정상 출력 / 관찰

local image ID가 출력된다. registry에서 pull/push한 적이 없는 local tag는 RepoDigests=[]일 수 있으며, 그 경우 release digest promotion은 검증되지 않은 상태다.

06 · HARDEN — production 확장

retention은 rollback window보다 길게, signature verification은 protected environment 앞에, base update는 자동 PR+재검증으로 둔다. OCI Distribution SpecificationSigstore documentationSLSA specificationGitHub Actions security hardening

07 · 코드와 설정 해부

실제 파일

container workflow는 source SHA에서 image·SBOM·scan artifact를 만들고 release workflow는 image_digest input만 받는다. github/actions-lock.json은 workflow ref와 검토된 commit을 연결한다.

이 설정이 없으면

tag를 release identity로 쓰거나 release에서 rebuild하면 test된 bytes와 배포 bytes의 연결이 끊긴다. retention이 rollback window보다 짧으면 정상 digest도 복구 전에 삭제될 수 있다.

08 · End-to-end trace

workflow run ID·source SHA·builder identity·digest·SBOM·deployment revision을 한 release ledger로 연결한다.

09 · BREAK IT — 실패 주입

같은 tag가 새 digest를 가리키게 만든 뒤 tag-based rollback이 다른 bytes를 실행하는 위험을 재현한다.

↳ registry deletion은 rollback·forensics 보존 정책을 확인한 뒤 수행한다.

10 · 테스트

digest immutability, action SHA pins, secret absence, SBOM presence, vulnerability policy와 signature verification을 검사한다.

13 · 운영 산출물

compromised artifact revoke, base CVE rebuild, signature failure, retention recovery runbook을 둔다.

14 · 완료 조건

15 · 자가시험

동일 commit을 prod 승격 시 다시 build하면 어떤 보장이 사라지는가?

01 · 냉정한 실체

04 · 내부 실행

API server가 인증·인가·admission 후 object를 저장하고 watch event를 발행한다. scheduler는 미할당 Pod에 node를 binding하고 kubelet은 runtime을 통해 sandbox와 containers를 만든다. Kubernetes cluster architectureKubernetes Deployments

05 · MINIMUM VERTICAL SLICE

검증 범위: kubernetes/overlays/dev render와 새 cluster의 object UID·ownerReference·event capture가 필요하다. docs/VERIFICATION.md의 cluster smoke만으로 controller chain 전체를 검증했다고 보지 않는다.

npm run lab -- k8s:up
kubectl get deploy,rs,pod -n infrastructure-lab -o wide
kubectl get events -n infrastructure-lab --sort-by=.lastTimestamp

정상 출력 / 관찰

generation/observedGeneration, ownerReference, scheduled node, ready container가 이어진다.

06 · HARDEN — production 확장

API version, field ownership, rollout timeout, disruption budget, node lifecycle, upgrade skew를 정책화한다. Kubernetes cluster architectureKubernetes Deployments

07 · 코드와 설정 해부

실제 파일

kubernetes/overlays/dev가 base Deployment·Service·RBAC·policy와 observability를 render하고, k8s-up이 kind API에 제출한다. ownerReference와 generation은 Deployment→ReplicaSet→Pod reconciliation을 잇는다.

이 설정이 없으면

observedGeneration·ownerReference·event를 보지 않으면 desired state 오류와 kubelet/runtime 오류를 같은 문제로 오진한다.

08 · End-to-end trace

git manifest → API request → etcd object → watch → ReplicaSet → Pod binding → CRI → process를 추적한다.

09 · BREAK IT — 실패 주입

존재하지 않는 image digest를 배포해 ImagePullBackOff의 event, kubelet retry와 rollout timeout을 관찰한다.

↳ kind cluster를 삭제해 API objects와 node containers를 함께 제거한다.

10 · 테스트

render/schema/policy, server-side dry-run, rollout, service smoke, failure event와 rollback을 단계별로 검사한다.

13 · 운영 산출물

Pending, CrashLoop, ImagePull, NotReady를 object/event/runtime 층으로 나눈 triage 표를 둔다.

14 · 완료 조건

15 · 자가시험

Deployment desired replicas는 3인데 Pod가 2개다. 어느 controller의 어떤 관찰값부터 볼 것인가?

01 · 냉정한 실체

04 · 내부 실행

각 controller는 Pod template hash·ordinal·node ownership·completion count 같은 다른 key로 desired state를 계산한다. Kubernetes workloadsKubernetes Deployments

05 · MINIMUM VERTICAL SLICE

검증 범위: docs/VERIFICATION.md의 migration Completed, API 2/2, worker 1/1과 rollout history가 local workload evidence다. StatefulSet/DaemonSet/CronJob 선택은 비교 학습이며 capstone 실행 증거가 아니다.

kubectl get deploy,rs,pod,job -n infrastructure-lab
kubectl rollout history deployment/api -n infrastructure-lab

정상 출력 / 관찰

Deployment revision과 Job Complete condition이 서로 다른 lifecycle로 나타난다.

06 · HARDEN — production 확장

terminationGracePeriod, lifecycle hook, update strategy, retry/backoff, deadline, concurrencyPolicy를 workload마다 설정한다. Kubernetes workloadsKubernetes Deployments

07 · 코드와 설정 해부

실제 파일

api/worker Deployment는 ReplicaSet revision과 long-running restart semantics를, migrations/job.yaml은 finite completion과 backoff를 선언한다. Kustomize overlay가 같은 image identity를 각 lifecycle에 연결한다.

이 설정이 없으면

server를 Job으로 두면 completion이 없고, migration을 Deployment로 두면 replica마다 반복될 수 있다. Stateful identity 요구 없이 StatefulSet을 쓰면 storage·rollout 부담만 늘어난다.

08 · End-to-end trace

controller revision → template hash → Pod UID → container ID를 연결한다.

09 · BREAK IT — 실패 주입

migration command를 실패시켜 Job backoff와 Deployment rollout이 별개임을 관찰한다.

↳ Job log를 보존한 뒤 TTL 또는 명시적 delete로 정리한다.

10 · 테스트

workload type policy, update simulation, completion, restart policy, rollback을 검사한다.

13 · 운영 산출물

revision rollback, stuck terminating Pod, failed Job, missed CronJob runbook을 구분한다.

14 · 완료 조건

15 · 자가시험

worker가 queue를 소비하지만 stable network identity는 필요 없다. StatefulSet이 필요한가?

01 · 냉정한 실체

04 · 내부 실행

scheduler는 allocatable과 requests를 비교한다. CPU limit은 throttling, memory limit 초과는 reclaim/OOM kill로 나타날 수 있다. QoS는 request/limit 조합에서 파생된다. Kubernetes resource managementLinux kernel cgroup v2

05 · MINIMUM VERTICAL SLICE

검증 범위: base manifest의 request/limit/PDB와 새 kubectl get/top/event capture를 함께 보아야 한다. manifest 존재만으로 throttling·OOM·eviction behavior는 검증되지 않는다.

kubectl get pod -n infrastructure-lab -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,QOS:.status.qosClass
kubectl top pod -n infrastructure-lab

정상 출력 / 관찰

Pod가 node에 분산되고 QoS·usage가 manifest intent와 비교 가능하다.

06 · HARDEN — production 확장

load test의 p95 CPU·working set에서 request를 시작하고 headroom, quota, priority, disruption을 함께 조정한다. Kubernetes resource managementLinux kernel cgroup v2

07 · 코드와 설정 해부

실제 파일

api/worker Deployment resources가 scheduler request와 kubelet cgroup limit을 분리하고, topologySpreadConstraints와 PDB가 placement·disruption을 제한한다. failure overlays는 Pending·OOM·PDB를 독립적으로 만든다.

이 설정이 없으면

request가 없으면 scheduler capacity signal이 틀리고, memory limit이 없으면 한 Pod가 node를 압박한다. PDB·topology spread가 없으면 drain이나 AZ loss 때 replica가 함께 사라질 수 있다.

08 · End-to-end trace

Pod Pending condition → scheduler FailedScheduling event → predicate/resource → node allocatable/cgroup을 추적한다.

09 · BREAK IT — 실패 주입

Pending/affinity/OOM/PDB fixture를 적용해 서로 다른 event·container reason을 비교한다.

↳ failure overlay와 stress Pod를 삭제하고 node taint를 복구한다.

10 · 테스트

requests/limits policy, Pending reason, OOMKilled, throttling metric, drain/PDB behavior를 검사한다.

13 · 운영 산출물

Pending, OOM, throttle, eviction, drain/PDB마다 확인 event·metric과 완화 순서를 둔다.

14 · 완료 조건

15 · 자가시험

CPU usage는 200m인데 request 2CPU인 Pod 10개 때문에 새 node가 생겼다. 어떤 값이 scheduler와 비용을 움직였나?

01 · 냉정한 실체

04 · 내부 실행

kubelet이 probe를 실행하고 status를 API에 쓴다. EndpointSlice controller는 Ready condition을 traffic endpoint에 반영한다. HPA는 sampled metric과 stabilization policy로 desired replicas를 계산한다. Kubernetes probesKubernetes resource management

05 · MINIMUM VERTICAL SLICE

검증 범위: docs/VERIFICATION.md는 readiness rollout과 HPA metric availability를 기록한다. TERM 중 endpoint 제거 순서와 queue-based scaling은 새 timestamp evidence가 필요하다.

kubectl describe pod -n infrastructure-lab -l app.kubernetes.io/name=api
kubectl get hpa -n infrastructure-lab -w

정상 출력 / 관찰

startup 이후 Ready=True, TERM 시 endpoint 제거와 bounded drain, metric availability가 관찰된다.

06 · HARDEN — production 확장

probe timeout/threshold, drain grace, HPA min/max, stabilization, queue-depth metric과 cold-start budget을 측정해 정한다. Kubernetes probesKubernetes resource management

07 · 코드와 설정 해부

실제 파일

api-deployment probe가 /health/live와 /health/ready를 분리하고 HPA가 CPU target/min/max를 선언한다. bad-probe와 bad-rollout overlay가 probe가 schema-valid여도 behavior를 망칠 수 있음을 보여준다.

이 설정이 없으면

dependency를 liveness에 넣으면 dependency outage가 restart storm으로 바뀐다. startup probe·drain grace·stabilization이 없으면 cold start와 scale oscillation이 정상 traffic을 끊는다.

08 · End-to-end trace

probe result → Pod condition → EndpointSlice → connection draining → rollout progress를 연결한다.

09 · BREAK IT — 실패 주입

dependency를 liveness에 묶은 bad probe로 CrashLoop를 만들고 liveness를 process-only로 고친다.

↳ load generator와 bad-probe overlay를 제거하고 HPA 상태를 정상화한다.

10 · 테스트

startup delay, live failure, ready failure, TERM under load, HPA delay와 scale-down stabilization을 검사한다.

13 · 운영 산출물

probe failure, rollout stall, HPA unknown metric, drain timeout별 runbook을 둔다.

14 · 완료 조건

15 · 자가시험

DB가 5분간 죽었다. API process를 재시작하면 안 되는 근거와 traffic 처리는?

01 · 냉정한 실체

04 · 내부 실행

CNI가 Pod interface/IP/routes를 만들고, EndpointSlice controller가 selector 결과를 기록하며, kube-proxy 또는 eBPF data plane이 Service traffic을 endpoint로 보낸다. Kubernetes Services and networkingGateway API Standard channel

05 · MINIMUM VERTICAL SLICE

검증 범위: docs/VERIFICATION.md의 NodePort smoke와 Calico default-deny timeout이 local path evidence다. AWS LB/Gateway/TLS 구간은 reference이며 EKS production evidence가 아니다.

kubectl get svc,endpointslice,pod -n infrastructure-lab -o wide
curl -fsS http://127.0.0.1:18080/health/ready

정상 출력 / 관찰

Service selector와 Ready Pod IP가 EndpointSlice에 일치하고 readiness가 200을 반환한다.

06 · HARDEN — production 확장

Gateway API Standard channel, TLS termination, externalTrafficPolicy, drain, timeout, NetworkPolicy와 DNS cache를 구현체 지원표와 함께 선택한다. Kubernetes Services and networkingGateway API Standard channel

07 · 코드와 설정 해부

실제 파일

api-service selector/port/targetPort가 Ready Pod EndpointSlice와 listener를 연결하고, Calico policy가 ingress/egress tuple을 허용한다. dev overlay의 NodePort 18080은 local client 진입점이다.

이 설정이 없으면

selector·targetPort·readiness 중 하나가 틀리면 DNS는 성공해도 endpoint 또는 response가 없다. CNI enforcement 확인 없이 NetworkPolicy object 존재를 격리 증거로 쓰면 안 된다.

08 · End-to-end trace

DNS answer → LB target → Service rule → EndpointSlice IP → Pod socket → DB return path를 tuple로 기록한다.

09 · BREAK IT — 실패 주입

bad selector, wrong targetPort, DNS name, default-deny policy를 각각 주입해 endpoint 없음과 packet drop을 구분한다.

↳ failure policy를 제거한 뒤 baseline policy를 재적용하고 connectivity regression을 확인한다.

10 · 테스트

Service DNS, endpoint readiness, direct Pod/Service path, ingress path, policy allowed/denied, drain을 검사한다.

13 · 운영 산출물

DNS, endpoint, route, policy, TLS, listener 순서의 packet-path runbook을 둔다.

14 · 완료 조건

15 · 자가시험

Service DNS와 ClusterIP connect는 성공하지만 HTTP 503이다. 다음 두 object는?

01 · 냉정한 실체

04 · 내부 실행

kubelet은 ConfigMap/Secret을 Pod에 투영하고 CSI driver가 volume lifecycle을 수행한다. environment 변수는 process 시작 때 snapshot이며 volume 갱신과 semantics가 다르다. Kubernetes storageKubernetes Pod Security Standards

05 · MINIMUM VERTICAL SLICE

검증 범위: kubernetes/secret.example.yaml, Deployment env refs, RBAC can-i와 restore ledger를 함께 본다. Secret rotation과 CSI snapshot은 local runtime으로 검증되지 않았다.

kubectl get configmap,secret,pvc -n infrastructure-lab
kubectl auth can-i get secrets --as=system:serviceaccount:infrastructure-lab:api -n infrastructure-lab

정상 출력 / 관찰

API ServiceAccount가 Secret list/get 권한을 갖지 않고, 필요한 key만 workload에 주입된다.

06 · HARDEN — production 확장

external secret manager·KMS envelope encryption·rotation overlap·CSI snapshot/backup와 restore drill을 서비스별 RPO/RTO에 맞춘다. Kubernetes storageKubernetes Pod Security Standards

07 · 코드와 설정 해부

실제 파일

secret.example은 key contract만 두고 Deployment가 필요한 key만 env로 참조한다. ServiceAccount/RBAC는 API read를 막고 PostgreSQL persistence·restore는 별도 경로다.

이 설정이 없으면

Secret object만 만들면 etcd at-rest encryption·rotation·redaction이 생기지 않는다. PVC만 만들면 backup·restore·RPO가 생기지 않는다.

08 · End-to-end trace

secret owner → encrypted store → workload identity → mount → process read → rotation → audit event를 추적한다.

09 · BREAK IT — 실패 주입

필수 secret key를 누락해 startup/readiness 실패를 만들고 event와 redacted log를 확인한다. backup fixture를 손상시켜 restore checksum 실패도 확인한다.

↳ 누락-secret fixture와 임시 restore database만 제거하고 baseline RBAC·readiness·restore query를 다시 실행한다.

10 · 테스트

secret pattern scan, RBAC can-i, manifest policy, rotation overlap, volume permission, backup checksum과 restore query를 검사한다.

13 · 운영 산출물

secret rotation, PVC Pending, mount permission, full disk, backup·restore runbook에 owner와 stop condition을 둔다.

14 · 완료 조건

15 · 자가시험

Secret object를 만들었는데 etcd snapshot을 읽는 공격자가 값을 얻었다. 어떤 통제가 빠졌나?

01 · 냉정한 실체

04 · 내부 실행

API server는 request identity를 인증하고 authorizer가 verb/resource/scope를 평가한 뒤 mutating/validating admission을 거친다. kubelet/runtime은 securityContext를 kernel controls로 번역한다. Kubernetes Pod Security StandardsAWS IAM best practices

05 · MINIMUM VERTICAL SLICE

검증 범위: base securityContext·ServiceAccount와 docs/VERIFICATION.md의 OPA 2/2 및 Calico deny가 local evidence다. managed admission·audit log·image signature enforcement는 미검증이다.

kubectl auth can-i --list --as=system:serviceaccount:infrastructure-lab:api -n infrastructure-lab
opa test policies/kubernetes

정상 출력 / 관찰

workload identity는 불필요한 Secret·cluster resource를 읽지 못하고 policy test가 privileged/hostPath를 거부한다.

06 · HARDEN — production 확장

Pod Security Standards Restricted, policy exception owner/expiry, image signature admission, audit retention과 dedicated node 조건을 운영 정책으로 둔다. Kubernetes Pod Security StandardsAWS IAM best practices

07 · 코드와 설정 해부

실제 파일

service-accounts.yaml과 rbac.yaml이 API identity를 제한하고 Deployment securityContext가 UID, seccomp, capability, filesystem 경계를 runtime으로 전달한다. Rego는 privileged/hostPath manifest를 거부한다.

이 설정이 없으면

runAsNonRoot만으로 wildcard RBAC·hostPath·unrestricted egress가 사라지지 않는다. policy test만 통과해도 cluster admission이 실제 enforce한다는 보장은 없다.

08 · End-to-end trace

subject → token audience → auth decision → RBAC binding → admission result → audit ID → runtime UID/capabilities를 연결한다.

09 · BREAK IT — 실패 주입

privileged, hostPath, Secret-reader, unrestricted egress fixture를 제출해 어느 gate가 거부하는지 증거를 남긴다.

↳ 공격 fixture와 임시 policy exception을 제거하고 baseline RBAC can-i, Rego, network deny와 workload securityContext를 재확인한다.

10 · 테스트

RBAC can-i, Rego unit test, server-side dry-run, image policy, network deny, audit event와 runtime securityContext를 검사한다.

13 · 운영 산출물

RBAC denial, admission rejection, compromised ServiceAccount, malicious image와 node compromise runbook을 구분한다.

14 · 완료 조건

15 · 자가시험

Pod가 runAsNonRoot지만 Secret list 권한과 unrestricted egress가 있다. 왜 여전히 위험한가?

01 · 냉정한 실체

04 · 내부 실행

Kustomize는 구조적 patch와 resource composition을, Helm은 Go template과 release state를 제공한다. hook은 main reconciliation 밖의 hidden lifecycle을 만들 수 있다. Kubernetes KustomizeKubernetes cluster architecture

05 · MINIMUM VERTICAL SLICE

검증 범위: docs/VERIFICATION.md의 14개 Kustomize render가 local evidence다. kubeconform·Conftest가 없으면 validator script는 명시적으로 SKIP하며 server-side dry-run은 cluster가 있을 때만 가능하다.

npm run lab -- k8s:validate

정상 출력 / 관찰

14개 target render는 필수다. kubeconform·Conftest·OPA는 설치된 경우만 실행되며, 없으면 PASS가 아니라 SKIP으로 출력된다.

06 · HARDEN — production 확장

environment 차이는 image digest, replicas, resources, endpoints처럼 허용된 patch에 제한하고 drift report를 source와 연결한다. Kubernetes KustomizeKubernetes cluster architecture

07 · 코드와 설정 해부

실제 파일

base가 공통 object를 소유하고 dev/canary/failure overlay가 좁은 patch를 적용한다. k8s-validate는 모든 render를 만든 뒤 설치된 schema/policy validator만 실행한다.

이 설정이 없으면

source YAML만 검사하면 overlay가 만든 duplicate·bad probe·secret leak을 놓친다. hook이나 patch 범위가 넓으면 environment drift review가 어려워진다.

08 · End-to-end trace

base commit → overlay patch → rendered object hash → applied field ownership → live diff를 추적한다.

09 · BREAK IT — 실패 주입

잘못된 probe patch와 누락 selector를 render해 schema는 통과하지만 behavior test가 실패하는 경계를 보여준다.

↳ 임시 rendered file을 삭제하고 failure overlay를 적용했다면 baseline dev overlay를 재적용한 뒤 live diff를 0으로 만든다.

10 · 테스트

모든 kustomization render, duplicate ID, schema, policy, secret scan, server dry-run, smoke와 rollback을 검사한다.

13 · 운영 산출물

render diff, failed hook, drift, rollback과 upstream dependency update runbook을 둔다.

14 · 완료 조건

15 · 자가시험

Helm lint가 통과했는데 Pod가 Ready가 아니다. lint가 잡지 못한 세 층은?

01 · 냉정한 실체

04 · 내부 실행

request는 SigV4/session credential로 인증되고 identity/resource policy, SCP 등 policy evaluation을 거친다. control-plane API 성공과 data-plane health는 별도다. AWS shared responsibility modelAWS IAM best practices

05 · MINIMUM VERTICAL SLICE

검증 범위: Terraform mock provider가 실제 AWS API 없이 dev/prod plan assertions를 평가한다. account credential, SCP, quota와 CloudTrail runtime은 UNVERIFIED다.

terraform -chdir=terraform/environments/dev test -no-color

정상 출력 / 관찰

dev test는 cluster name과 private subnet 2개 output을 assert하고 configuration check가 admin/account input을 평가한다. tag·IAM policy behavior나 실제 AWS API는 검증하지 않는다.

06 · HARDEN — production 확장

multi-account boundary, break-glass MFA, STS session duration, SCP, KMS key ownership, CloudTrail log immutability와 quota review를 정한다. AWS shared responsibility modelAWS IAM best practices

07 · 코드와 설정 해부

실제 파일

environment provider는 region과 allowed_account_ids를 받으며 production check가 정확히 한 account를 요구한다. cluster_admin check는 명시된 role 없이는 plan을 거부한다.

이 설정이 없으면

account allowlist·temporary role·CloudTrail owner가 없으면 올바른 code도 잘못된 account에서 감사 불가능하게 실행될 수 있다.

08 · End-to-end trace

human/workflow identity → federation → STS role session → API request ID → CloudTrail event → resource change를 연결한다.

09 · BREAK IT — 실패 주입

expired STS, explicit deny, quota exceeded, wrong Region을 서로 다른 error code와 CloudTrail evidence로 구분한다.

↳ mock test는 cloud resource를 만들지 않는다. 생성된 temporary plan output만 폐기하고 lock/configuration은 보존한다.

10 · 테스트

policy JSON parse, least-privilege review, mock Terraform tests, tag/region constraints, destructive-action guard를 검사한다.

13 · 운영 산출물

credential expiry, access denied, quota, Region mismatch와 account compromise runbook을 둔다.

14 · 완료 조건

15 · 자가시험

CloudFormation/Terraform API call이 성공하면 application이 healthy라는 뜻인가?

01 · 냉정한 실체

04 · 내부 실행

route table이 next hop을 고르고 security group은 stateful, NACL은 subnet-level stateless filter다. NAT gateway는 outbound translation state와 per-byte cost를 가진다. AWS VPC documentationAWS Well-Architected Cost Optimization

05 · MINIMUM VERTICAL SLICE

검증 범위: network/observability module source와 mock output assertions를 검토한다. route reachability, SG/NACL behavior, ALB health와 NAT failover는 실제 AWS에서 검증되지 않았다.

terraform -chdir=terraform/environments/dev test -no-color

정상 출력 / 관찰

mock test는 dev cluster name과 private subnet 2개 output만 직접 assert한다. route/NAT/flow-log/encryption은 source review 대상이며 live behavior나 apply 성공 증거가 아니다.

06 · HARDEN — production 확장

CIDR growth, subnet IP exhaustion, per-AZ NAT vs shared NAT, endpoint coverage, DNS split-horizon, flow-log retention을 ADR로 고정한다. AWS VPC documentationAWS Well-Architected Cost Optimization

07 · 코드와 설정 해부

실제 파일

network module이 VPC, public/private route tables, IGW와 configurable NAT를 구성하고 observability module이 flow log/KMS를 연결한다. dev는 single NAT, prod는 per-AZ NAT라는 project policy다.

이 설정이 없으면

private label만 붙여도 IGW route·public IP·SG/NACL·return path가 자동으로 바뀌지 않는다. NAT 하나는 비용을 줄이지만 cross-AZ/SPOF risk를 만든다.

08 · End-to-end trace

DNS answer → IGW/ALB ENI → target group → node/Pod ENI → DB SG와 return path를 flow tuple로 추적한다.

09 · BREAK IT — 실패 주입

missing return route, SG egress, NACL ephemeral port, unhealthy target, NAT failure를 symptom과 flow-log action으로 구분한다.

↳ mock/provider run은 apply가 없으므로 cloud teardown도 없다. temporary scan output만 제거하고 no-apply boundary를 기록한다.

10 · 테스트

Terraform mock, route/SG assertions, IaC scan, CIDR overlap, subnet capacity와 packet-path tabletop을 검사한다.

13 · 운영 산출물

DNS, certificate, ALB target, route, SG/NACL, NAT, IP exhaustion runbook을 packet 순서로 둔다.

14 · 완료 조건

15 · 자가시험

private subnet workload가 S3로 갈 때 NAT 비용을 피할 수 있는 설계와 새 failure boundary는?

01 · 냉정한 실체

04 · 내부 실행

EC2는 guest OS와 scheduler 책임이 사용자에게, ECS/EKS는 orchestration control plane 일부가 AWS에, Lambda는 execution environment lifecycle 대부분이 서비스에 있다. AWS compute services decision guideAWS shared responsibility model

05 · MINIMUM VERTICAL SLICE

검증 범위: 이 모듈의 6-option decision table과 ADR은 비교 근거다. 실제 EC2/ASG/ECS/Fargate/EKS/Lambda pilot의 deploy time·incident load·cost는 측정되지 않았다.

node -e "process.stdout.write(require('node:fs').readFileSync('docs/adr/0002-terraform-eks-reference.md','utf8'))"

정상 출력 / 관찰

사이트 표는 EC2, ASG, ECS on EC2, Fargate, EKS, Lambda를 모든 필수 축에서 비교한다. ADR은 project 선택을 설명할 뿐 실제 pilot 결과가 아니다.

06 · HARDEN — production 확장

reversible pilot에서 deploy time, incident load, idle cost, scaling lag, security control coverage를 측정한다. AWS compute services decision guideAWS shared responsibility model

07 · 코드와 설정 해부

실제 파일

decision table이 control/ops, scaling/cold start, network/IAM/observability, cost와 fit/no-fit을 option별로 분리하고 ADR이 capstone의 EKS 학습 target과 ECS/Fargate 대안을 기록한다.

이 설정이 없으면

ASG를 EC2와 합치거나 ECS와 Fargate를 같은 billing/host model로 보면 patching·capacity·cold-start 책임을 잘못 배분한다.

08 · End-to-end trace

source artifact가 각 option의 scheduler/runtime/network identity를 지나 request를 처리하는 경계를 비교한다.

09 · BREAK IT — 실패 주입

node/Task/Pod/function cold start, quota, image pull, AZ failure 시 누가 복구하는지 tabletop으로 비교한다.

↳ 이 module은 cloud resource를 만들지 않는다. pilot을 했다면 option별 temporary resource·IAM role·log group의 owner와 삭제 evidence가 필요하다.

10 · 테스트

decision criteria weight, representative deploy, load/scale, failure recovery, IAM and cost estimate를 option별로 검증한다.

13 · 운영 산출물

각 option의 deploy rollback, capacity, platform outage와 escalation runbook owner를 정한다.

14 · 완료 조건

15 · 자가시험

두 명 팀의 HTTP API 하나에 EKS가 더 나은 선택이 되려면 어떤 추가 요구가 실제로 있어야 하나?

01 · 냉정한 실체

04 · 내부 실행

AWS가 control-plane endpoint/etcd availability를 운영하지만 kubelet과 CNI는 node에서 Pod IP·routes를 구성한다. workload AWS access는 cluster role이 아니라 scoped workload identity를 써야 한다. Amazon EKS best practicesAWS Well-Architected Reliability Pillar

05 · MINIMUM VERTICAL SLICE

검증 범위: cluster module source와 mock plan output을 검토한다. 실제 EKS endpoint, add-on compatibility, Pod Identity exchange, upgrade와 node drain은 모두 UNVERIFIED다.

terraform -chdir=terraform/environments/dev test -no-color

정상 출력 / 관찰

dev mock test가 cluster name과 private subnet 2개 output을 직접 assert한다. encryption/logging/node group/IAM은 configuration에 존재하지만 test assertion이나 live AWS behavior로 검증되지 않는다.

06 · HARDEN — production 확장

supported version cadence, add-on compatibility, surge node capacity, drain/PDB, private endpoint access, CNI IP capacity와 break-glass를 정한다. Amazon EKS best practicesAWS Well-Architected Reliability Pillar

07 · 코드와 설정 해부

실제 파일

cluster module이 control-plane encryption/logging, managed node group, access entries와 aws-node Pod Identity role을 선언하고 network private subnet outputs를 입력으로 받는다.

이 설정이 없으면

managed control plane을 cluster 전체 관리로 오해하면 add-on skew, node patch, CNI IP, workload IAM과 data recovery owner가 비게 된다.

08 · End-to-end trace

GitHub OIDC → ECR digest → Kubernetes API → scheduler → managed node/kubelet → VPC CNI ENI → ALB target을 연결한다.

09 · BREAK IT — 실패 주입

CNI IP exhaustion, add-on mismatch, node drain/PDB, private endpoint loss, registry pull, workload identity denial을 tabletop한다.

↳ mock test는 cloud teardown이 없다. local init cache를 정리하더라도 lockfile·source를 보존하고 no-apply evidence를 남긴다.

10 · 테스트

Terraform mock/static scan, local Kubernetes behavior, API deprecation scan, add-on matrix와 upgrade rehearsal을 분리한다.

13 · 운영 산출물

upgrade, node replacement, CNI, CoreDNS, CSI, ALB controller와 access recovery runbook을 각각 소유한다.

14 · 완료 조건

15 · 자가시험

EKS control plane SLA가 있어도 single node group이 한 AZ에만 있으면 어떤 failure가 남나?

01 · 냉정한 실체

04 · 내부 실행

RDS/Aurora, DynamoDB, S3, ElastiCache, SQS/SNS/MSK, EBS/EFS는 replication unit, consistency, delivery와 failure semantics가 다르다. AWS databases decision guideAWS Well-Architected Reliability Pillar

05 · MINIMUM VERTICAL SLICE

검증 범위: PostgreSQL/Redis capstone behavior는 Compose integration과 restore ledger로 local 검증됐다. RDS/Aurora, DynamoDB, S3, ElastiCache, SQS, SNS, MSK, EBS/EFS 표는 AWS reference이며 runtime evidence가 아니다.

node scripts/verify-runtime.mjs --compose

정상 출력 / 관찰

성공 job, capacity-one rejection, 3회 bounded retry와 trace correlation이 실제 PostgreSQL/Redis에서 통과한다.

06 · HARDEN — production 확장

RDS Multi-AZ, PITR, connection pool, Redis eviction/failover, queue DLQ와 client retry/idempotency를 RPO/RTO에 맞춘다. AWS databases decision guideAWS Well-Architected Reliability Pillar

07 · 코드와 설정 해부

실제 파일

API transaction이 job/outbox를 한 PostgreSQL commit에 쓰고 relay가 Redis Stream에 publish하며 worker가 advisory lock/idempotency로 중복을 흡수한다. comparison table은 다른 managed service의 책임을 별도로 둔다.

이 설정이 없으면

Redis를 source of truth로 취급하면 eviction/failover가 data loss가 된다. managed service 이름만 보고 consistency·backup·network·IAM·quota를 생략하면 failure mode가 사라지지 않고 숨는다.

08 · End-to-end trace

API transaction ID → outbox row → stream ID → worker attempt → final row status와 backup LSN을 연결한다.

09 · BREAK IT — 실패 주입

DB unavailable, Redis unavailable, connection exhaustion, duplicate delivery, restore corruption을 각각 주입해 source-of-truth behavior를 확인한다.

↳ Compose/restore fixture, source/target database와 volume을 제거하고 job/outbox/stream 상태가 baseline에서 재현되는지 다시 확인한다.

10 · 테스트

transaction, duplicate/idempotency, retry/dead-letter, pool saturation, failover tabletop, backup checksum과 restore query를 검사한다.

13 · 운영 산출물

DB failover, pool exhaustion, cache loss, queue backlog, poison message와 restore runbook을 구분한다.

14 · 완료 조건

15 · 자가시험

Redis Stream publish가 실패했지만 PostgreSQL job row는 commit됐다. job을 잃지 않는 mechanism은?

01 · 냉정한 실체

04 · 내부 실행

Terraform은 provider schema와 refresh 결과로 graph를 만들고 state address와 remote IDs를 비교한다. lifecycle ignore는 drift를 해결하지 않고 숨길 수 있다. Terraform language and stateTerraform testsAWS IAM best practices

05 · MINIMUM VERTICAL SLICE

검증 범위: docs/VERIFICATION.md의 Terraform 1.15.8 fmt/init/validate와 dev/prod mock test가 local evidence다. credentialed refresh, saved plan, remote backend lock와 apply는 실행되지 않았다.

npm run lab -- terraform

정상 출력 / 관찰

fmt -check, dev/prod init -backend=false, validate와 각 mock test가 통과한다. 이 command는 TFLint·Trivy, credentialed refresh, real plan/apply를 실행하지 않는다.

06 · HARDEN — production 확장

versioned encrypted remote backend, lock, break-glass import, saved-plan approval, drift schedule, provider upgrade와 destroy protection을 둔다. Terraform language and stateTerraform testsAWS IAM best practices

07 · 코드와 설정 해부

실제 파일

modules/network|cluster|registry|observability가 environment roots에 composition되고 provider lock·variables·outputs·checks가 graph boundary를 만든다. validation script는 dev/prod를 같은 순서로 검사한다.

이 설정이 없으면

local state나 mock PASS를 real drift/plan/apply 성공으로 읽으면 credential, quota, provider API, remote lock와 side effect를 놓친다.

08 · End-to-end trace

PR diff → static checks → provider reads → saved plan hash → approval → apply ID → state version → CloudTrail change를 연결한다.

09 · BREAK IT — 실패 주입

out-of-band drift, stale lock, provider version mismatch, sensitive output, accidental destroy plan을 fixture/tabletop으로 검사한다.

↳ init cache와 temporary plan만 정리하고 source·lockfile·state backup은 보존한다. 실제 destroy는 이 lab의 teardown이 아니다.

10 · 테스트

fmt, validate, module mock tests, lint, IaC security, policy, plan review와 drift read-only workflow를 계층화한다.

13 · 운영 산출물

drift, lock, failed partial apply, import/move, provider regression, state recovery와 rollback/roll-forward runbook을 둔다.

14 · 완료 조건

15 · 자가시험

terraform validate와 mock test가 통과했다. 무엇이 여전히 unverified인가?

01 · 냉정한 실체

04 · 내부 실행

runner는 격리된 job filesystem에서 steps를 실행하고 artifact/cache service에 bytes를 올린다. CD는 environment credential과 concurrency를 획득한 뒤 immutable input을 배포한다. GitHub Actions documentationGitHub Actions security hardeningSLSA specification

05 · MINIMUM VERTICAL SLICE

검증 범위: local checker가 workflow 구조·권한·SHA·OIDC·digest 승격 계약을 검사한다. hosted run과 실제 배포는 검증하지 않았다.

npm run lab -- workflows

정상 출력 / 관찰

local checker가 5개 workflow, lock된 action ref, job permission, concurrency, OIDC trust와 digest promotion marker를 검사한다.

06 · HARDEN — production 확장

branch protection, required checks, environment approval, deploy timeout, canary metric gate, artifact retention와 rollback owner를 정책화한다. GitHub Actions documentationGitHub Actions security hardeningSLSA specification

07 · 코드와 설정 해부

실제 파일

5개 workflow가 CI, image, infra plan, release promotion, drift 역할을 나누고 lock file과 OIDC trust fixture가 경계를 고정한다.

이 설정이 없으면

hosted runner, branch protection, environment approval, registry와 cloud credential behavior는 local checker 밖이다.

08 · End-to-end trace

commit SHA → workflow/run attempt → image digest → environment approval → Deployment revision → request trace/SLO를 release ledger로 잇는다.

09 · BREAK IT — 실패 주입

중복 release, poisoned cache, flaky test, missing secret, bad rollout과 incompatible migration을 별도 gate에서 주입한다.

↳ checker가 만든 임시 산출물만 지우고 workflow·lock·trust source는 보존한다.

10 · 테스트

unit/integration, manifest/policy/security, artifact identity, concurrency, environment dry run, smoke, canary, rollback과 restore를 계층화한다.

13 · 운영 산출물

stuck queue, runner outage, registry failure, approval bypass, bad deploy와 schema recovery runbook을 둔다.

14 · 완료 조건

15 · 자가시험

release workflow가 source를 checkout해 image를 다시 build한다. 어떤 delivery invariant를 위반하나?

01 · 냉정한 실체

04 · 내부 실행

GitHub가 event context를 만들고 runner가 action code와 shell을 실행한다. GITHUB_TOKEN permission은 job에 발급되고 OIDC token은 audience/subject claims로 cloud role을 교환한다. GitHub Actions documentationGitHub Actions security hardening

05 · MINIMUM VERTICAL SLICE

검증 범위: check-workflow-security.mjs가 repository의 고정 계약을 source-level로 검사한다. GitHub-hosted parser/runtime evidence는 아니다.

npm run lab -- workflows

정상 출력 / 관찰

고정된 action mapping, exact permission, concurrency, unsafe run interpolation, OIDC subject와 digest flow 위반이 local checker에서 실패한다.

06 · HARDEN — production 확장

protected environments, exact OIDC subjects, reusable workflow input types, timeout-minutes, artifact retention, runner isolation과 audit review를 둔다. GitHub Actions documentationGitHub Actions security hardening

07 · 코드와 설정 해부

실제 파일

workflow files, actions-lock.json, exact job permissions, concurrency, unsafe interpolation checks와 OIDC trust subjects가 한 검사 경로에 있다.

이 설정이 없으면

실제 event context, secret masking, cache service, environment rule와 runner isolation은 재현하지 않는다.

08 · End-to-end trace

event actor/ref → run ID/attempt → job token permissions → OIDC sub → AWS role session → artifact digest → deployment를 연결한다.

09 · BREAK IT — 실패 주입

동일 ref 중복 배포, malicious PR title shell input, cache key collision, expired artifact와 OIDC subject mismatch를 fixture review한다.

↳ 검사는 read-only다. fixture를 바꿨다면 복원하고 생성된 local output만 정리한다.

10 · 테스트

actionlint/YAML parse, custom security checker, policy JSON, dry-run scripts와 hosted-run evidence를 분리한다.

13 · 운영 산출물

runner capacity, token permission, OIDC, cache corruption, artifact expiry와 environment approval runbook을 둔다.

14 · 완료 조건

15 · 자가시험

action을 tag로 pin하고 maintainer가 tag를 이동했다. 왜 lockfile만으로 충분하지 않은가?

01 · 냉정한 실체

04 · 내부 실행

Deployment는 maxSurge/maxUnavailable로 ReplicaSet 수를 조절한다. traffic shifting은 Service/Gateway/mesh controller가 endpoint weights를 바꾸며 metric controller와 atomic하지 않다. Kubernetes DeploymentsKubernetes probes

05 · MINIMUM VERTICAL SLICE

검증 범위: local cluster rollback drill의 exit status와 smoke 결과가 evidence다. production traffic shifting은 아니다.

npm run lab -- k8s:rollback

정상 출력 / 관찰

bad ReplicaSet은 0 Ready, rollout timeout, undo recovery, baseline reapply와 post-rollback job 성공이 순서대로 확인된다.

06 · HARDEN — production 확장

error/latency/saturation gate, minimum sample, bake time, maxUnavailable, manual stop, roll-forward와 expand/contract migration을 명시한다. Kubernetes DeploymentsKubernetes probes

07 · 코드와 설정 해부

실제 파일

bad-readiness overlay, rollout timeout, undo, baseline reapply와 post-rollback smoke가 한 bounded script에 있다.

이 설정이 없으면

canary weights, real user traffic, schema migration와 external side effects는 빠져 있다.

08 · End-to-end trace

release digest → revision → Pod labels → traffic weight → request metric/trace → gate decision → rollback revision을 연결한다.

09 · BREAK IT — 실패 주입

readiness failure, elevated error, slow response, drain loss와 incompatible schema를 별도 fixture로 주입한다.

↳ script cleanup과 baseline reapply를 완료하고 namespace 상태를 확인한다.

10 · 테스트

render/policy, rollout status, live traffic, error metric, drain, rollback, forward/backward schema contract와 recovery를 검사한다.

13 · 운영 산출물

abort authority, metric blind spot, stuck rollout, partial migration와 roll-forward decision runbook을 둔다.

14 · 완료 조건

15 · 자가시험

canary error rate는 낮지만 표본이 12 requests뿐이다. 승격하면 안 되는 이유는?

01 · 냉정한 실체

04 · 내부 실행

Argo CD/Flux 계열 controller는 repository revision을 fetch/render하고 API server에 apply하며 health·drift를 watch한다. controller credential은 cluster mutation 권한이다. OpenGitOps principlesKubernetes Kustomize

05 · MINIMUM VERTICAL SLICE

검증 범위: Kustomize source와 kubectl diff는 desired/live 비교 연습이다. repository에는 GitOps controller runtime evidence가 없다.

kubectl diff -k kubernetes/overlays/dev

정상 출력 / 관찰

live drift가 desired render와 비교 가능하고 promotion은 digest patch PR로 표현된다.

06 · HARDEN — production 확장

repo/branch/environment topology, sync windows, prune/self-heal, health customization, secret encryption, bootstrap/DR와 controller upgrade를 정한다. OpenGitOps principlesKubernetes Kustomize

07 · 코드와 설정 해부

실제 파일

base/overlay render와 digest patch PR pattern이 desired-state boundary를 표현한다.

이 설정이 없으면

controller, repository credential, sync health, prune policy와 promotion automation은 없다.

08 · End-to-end trace

PR commit → reconciliation revision → applied object annotation → live health → deployment digest → incident rollback commit을 연결한다.

09 · BREAK IT — 실패 주입

repository unavailable, bad render, controller credential loss, drift loop, accidental prune와 secret decryption failure를 tabletop한다.

↳ 연습용 live mutation을 baseline overlay로 되돌리고 diff가 비었는지 확인한다.

10 · 테스트

render/policy, controller dry run, health semantics, drift, prune safety, bootstrap restore와 credential scope를 검사한다.

13 · 운영 산출물

sync stuck, auth, bad prune, drift storm, controller upgrade와 bootstrap recovery runbook을 둔다.

14 · 완료 조건

15 · 자가시험

incident 중 kubectl hotfix가 self-heal로 즉시 되돌아간다. 무엇을 사전에 정했어야 하나?

01 · 냉정한 실체

04 · 내부 실행

application instruments counters/histograms and W3C context; Prometheus scrapes cumulative series; trace exporters batch spans. histogram bucket과 label cardinality가 query cost와 accuracy를 결정한다. OpenTelemetry Specification 1.59.0Prometheus metric types

05 · MINIMUM VERTICAL SLICE

검증 범위: Prometheus config/rule checks와 local target query가 evidence다. retention·paging backend는 포함되지 않는다.

kubectl -n infrastructure-lab port-forward svc/prometheus 19090:9090
curl -fsS 'http://127.0.0.1:19090/api/v1/targets'

정상 출력 / 관찰

API 2개와 worker 1개 target이 up=1, 7/7 rule health ok, queue/request/error/latency series가 실제 label과 일치한다.

06 · HARDEN — production 확장

SLI별 source, histogram buckets, sampling, retention, redaction, dashboard owner와 telemetry-loss alert를 정한다. OpenTelemetry Specification 1.59.0Prometheus metric types

07 · 코드와 설정 해부

실제 파일

API/worker metrics, Service discovery, Prometheus scrape config와 seven rules가 infrastructure-lab namespace에 연결된다.

이 설정이 없으면

production retention, remote write, trace backend, paging delivery와 telemetry SLO는 없다.

08 · End-to-end trace

정상/실패 request의 trace ID를 API log → outbox → Redis stream → worker attempts → database status와 비교한다.

09 · BREAK IT — 실패 주입

Prometheus worker scrape를 NetworkPolicy로 차단해 target down을 만들고 policy ingress 수정 후 recovery와 rule health를 확인한다.

↳ port-forward를 종료하고 failure fixture를 baseline NetworkPolicy로 복원한다.

10 · 테스트

metric names/labels, promtool config/rules, target up, histogram query, trace propagation, log schema/redaction와 cardinality budget을 검사한다.

13 · 운영 산출물

no data, target down, cardinality explosion, ingestion lag, query overload와 trace sampling runbook을 둔다.

14 · 완료 조건

15 · 자가시험

error counter는 증가하지만 trace에는 실패가 없다. 가능한 두 관찰 편향은?

01 · 냉정한 실체

04 · 내부 실행

burn rate는 선택한 window에서 허용 budget보다 얼마나 빠르게 bad events를 소비하는지 나타낸다. alert pipeline과 paging channel도 dependency다. Google SRE workbook — alerting on SLOsPrometheus metric types

05 · MINIMUM VERTICAL SLICE

검증 범위: runbook source와 local event timeline은 tabletop evidence다. 실제 page/incident response timing은 검증하지 않았다.

node -e "process.stdout.write(require('node:fs').readFileSync('runbooks/kubernetes-incident.md','utf8'))"
kubectl get events -A --sort-by=.lastTimestamp

정상 출력 / 관찰

detect, declare, assign commander, mitigate, verify, communicate, recover, follow-up 단계와 stop condition이 명시된다.

06 · HARDEN — production 확장

SLI source/denominator, SLO window, budget policy, multi-window alerts, severity matrix, communication cadence와 action owner/expiry를 정한다. Google SRE workbook — alerting on SLOsPrometheus metric types

07 · 코드와 설정 해부

실제 파일

incident runbook이 detection, roles, mitigation, verification, communication와 stop conditions를 연결한다.

이 설정이 없으면

paging provider, on-call acknowledgment, stakeholder channel와 measured MTTD/MTTR evidence는 없다.

08 · End-to-end trace

release/change ID → first bad SLI → alert fire → acknowledgment → mitigation → SLI recovery → closure를 UTC timeline으로 기록한다.

09 · BREAK IT — 실패 주입

bad deploy, node drain, DB/DNS/certificate/registry/secret/resource 장애를 tabletop 또는 local fixture로 주입한다.

↳ fixture를 baseline으로 복원하고 incident 기록에 cleanup·owner·follow-up을 남긴다.

10 · 테스트

alert expression, notification path, runbook command, access, rollback, restore, communication template와 action closure를 game day에서 검사한다.

13 · 운영 산출물

runbook에는 owner, symptom, safe diagnostics, mitigation, rollback, escalation, verification와 stop condition을 둔다.

14 · 완료 조건

15 · 자가시험

CPU 95% alert가 울렸지만 latency/error는 정상이다. 바로 page해야 하나?

01 · 냉정한 실체

04 · 내부 실행

provenance는 누가 어떤 input으로 artifact를 만들었는지 attestation하고 signature는 key identity와 bytes binding을 검증한다. 둘 다 trusted builder policy와 runtime authorization을 대신하지 않는다. Sigstore documentationSLSA specificationGitHub Actions security hardeningKubernetes Pod Security Standards

05 · MINIMUM VERTICAL SLICE

검증 범위: dependency audit와 workflow checker의 local results만 기본 evidence다. OPA/Trivy/signing은 설치·실행 evidence 없이는 UNVERIFIED다.

npm audit --omit=dev --prefix app/api
npm run lab -- workflows

정상 출력 / 관찰

기본 command는 dependency advisory와 repository workflow contracts만 검사한다. manifest/IaC/image/signature controls는 별도 evidence가 필요하다.

06 · HARDEN — production 확장

threat model, dependency/base update SLA, signing keyless identity, admission enforcement, KMS rotation, WAF/TLS, CloudTrail/audit와 incident exercises를 둔다. Sigstore documentationSLSA specificationGitHub Actions security hardeningKubernetes Pod Security Standards

07 · 코드와 설정 해부

실제 파일

dependency graph와 workflow trust boundary가 기본 command에 있고 manifest/IaC/image controls는 별도 도구 층이다.

이 설정이 없으면

runtime identity/network negative test, signature verification와 incident revoke exercise는 기본 command에 없다.

08 · End-to-end trace

source reviewer → action SHA → builder OIDC → provenance/digest → registry → admission decision → workload identity → data access → audit event를 연결한다.

09 · BREAK IT — 실패 주입

untrusted image, malicious action ref, leaked secret, overprivileged SA, unrestricted egress와 expired certificate를 각 control에서 주입한다.

↳ scanner cache/output만 정리하고 finding과 exception ledger는 보존한다.

10 · 테스트

secret/dependency/image/IaC/workflow/policy scans, runtime identity/network negative tests, audit query, revoke/rotate와 recovery drill을 계층화한다.

13 · 운영 산출물

credential revoke, artifact quarantine, certificate rotation, dependency zero-day, cluster compromise와 forensic retention runbook을 둔다.

14 · 완료 조건

15 · 자가시험

image signature는 유효하지만 builder workflow가 탈취됐다. 무엇이 추가로 필요한가?

01 · 냉정한 실체

04 · 내부 실행

replication은 corruption/deletion도 복제할 수 있고 backup은 restore path·key·catalog가 필요하다. autoscaling은 quota, warm-up, dependency capacity와 feedback lag를 가진다. AWS Well-Architected Reliability PillarAWS Well-Architected Cost OptimizationGoogle SRE workbook — alerting on SLOs

05 · MINIMUM VERTICAL SLICE

검증 범위: local restore와 rollback scripts의 bounded success가 evidence다. AWS AZ/Region failover와 stated RPO/RTO는 tabletop이다.

npm run lab -- restore
npm run lab -- k8s:rollback

정상 출력 / 관찰

PostgreSQL isolated restore와 Kubernetes rollback drill은 별도 local evidence를 만든다. AWS Region/AZ recovery는 reference/tabletop으로 남는다.

06 · HARDEN — production 확장

service tier별 RPO/RTO, backup frequency/retention, immutable copy, restore cadence, quota/headroom, failover authority와 cost ceiling을 정한다. AWS Well-Architected Reliability PillarAWS Well-Architected Cost OptimizationGoogle SRE workbook — alerting on SLOs

07 · 코드와 설정 해부

실제 파일

PostgreSQL backup→isolated restore와 Kubernetes bad rollout→undo→smoke를 분리된 recovery paths로 실행한다.

이 설정이 없으면

regional dependency, DNS, KMS/key recovery, quota와 timed production-scale restore는 없다.

08 · End-to-end trace

last good transaction/backup ID → failure time → detection → restore/failover steps → first healthy request → reconciliation complete를 기록한다.

09 · BREAK IT — 실패 주입

AZ/node loss, DB unavailable, DNS/certificate, registry, quota, backup corruption, region tabletop와 dependency saturation을 주입한다.

↳ restore container/data와 rollback fixture를 정리하고 baseline service health를 다시 확인한다.

10 · 테스트

backup checksum만이 아니라 isolated restore, integrity query, application smoke, RPO gap, timed RTO, failback와 cleanup을 검사한다.

13 · 운영 산출물

failover/restore에는 declare authority, data-loss estimate, communication, integrity check, failback, cost guard와 abort condition을 둔다.

14 · 완료 조건

15 · 자가시험

매일 backup은 성공하지만 복원에 14시간이 걸리고 RTO는 2시간이다. 상태는 green인가?