N° 01 — 목록
'Cloud & Infrastructure/Kubernetes Security' (10)
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 10. audit runtime-security
정적 방어를 넘어 "지금 무슨 일이 일어나는가"를 잡는 법 — 감사와 런타임 보안한 클러스터에서 침해가 일어났다. 공격자는 권한을 올리고 비밀을 빼갔지만, 발견은 며칠 뒤였다. 아무도 실시간으로 "이상한 일이 돌아가고 있다"를 못 봤기 때문이다. 지금까지의 정적 방어 — RBAC·NetworkPolicy·Pod Security — 는 "들어오는 것"을 막는 데는 강하지만, 이미 들어와서 행동하는 것은 잡지 못한다. 이 빈을 메우는 두 축이 감사 로그(audit log)와 런타임 보안(Falco)이다. 전자는 "누가 무엇을 했나"를 사후에 기록하고, 후자는 "지금 커널에서 무슨 일이 일어나나"를 실시간으로 잡는다. 이 글은 03-k8s-security 영역의 마지막 주제로, 이 두 관측 축이 침해를 어떻게..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 09. network security
"내부라서 안전하다"를 부정하는 모델 — zero-trust와 네트워크 보안한 조직이 클러스터 네트워크를 "내부는 믿을 수 있다"는 가정 위에 세웠다. Pod는 서로 자유롭게 통신했고, NetworkPolicy는 없었다(이게 Kubernetes의 기본값이다 ). 그러다 한 Pod가 취약점으로 뚫렸다. 공격자는 그 Pod에서 출발해 클러스터 전체를 횡단했다. 다른 Pod로의 연결을 막는 벽이 아예 없었으니까. zero-trust는 바로 이 가정을 부정한다 — "내부도 불신한다. 누가 누구와 통신하나를 명시적으로 허용한다." 이 글은 네트워크 보안이 이 원칙을 어떻게 실현하고, 이미 본 NetworkPolicy와 Calico/Cilium 정책·메시 정책이 어떻게 함께 한 벽이 되는지를 따진다.zero-tru..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 08, mtls supply-chain
전송 구간 암호화와 이미지 서명이 막는 다른 위협 — mTLS와 공급망 보안한 팀이 두 가지 사고를 겪었다. 첫째, 같은 클러스터 안의 두 서비스가 평문으로 통신하고 있었는데 노드가 탈취됐다. 공격자는 그 노드에서 패킷을 가로채 비밀을 빼냈다. "내부니까 안전하다"는 가정이 무너진 순간이었다. 둘째, 같은 팀이 배포 파이프라인을 점검하다가 레지스트리의 이미지가 빌드한 것과 다르다는 걸 발견했다. 중간에 누군가 바꿔치기한 것이다. 두 사고는 전혀 다른 공격 경로에서 왔고, 그래서 방어도 다른 두 축이 필요하다 — 전송을 암호화하는 mTLS와, 이미지 출처를 증명하는 서명(cosign/Sigstore). 이 글은 이 두 축이 각각 무엇을 막고, 어떻게 공급망 보안의 한 벽돌이 되는지를 따진다.전송과 출처는 ..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 07. cert-manager
인증서 만료는 클러스터의 타이머 폭탄이다 — cert-manager가 자동화하는 것14장에서 kubeadm 인증서가 1년 만료라고 했다. 잊고 있던 어느 날, apiserver 인증서가 만료돼 클러스터가 멈췄다 — 아무것도 연결이 안 됐다. 인증서 만료는 Kubernetes의 타이머 폭탄이다. cert-manager가 그 폭탄을 자동 해체한다 — 발급·갱신·배포를 코드로. 단지 kubeadm 시스템 인증서가 아니라, 앱의 TLS 인증서까지.이 글이 푸는 것은: cert-manager가 인증서 생명주기를 어떻게 자동화하고, Issuer/ClusterIssuer가 무엇인가다.인증서가 Kubernetes에서 왜 그렇게 흔한가flowchart LR USE["인증서 사용처"] --> A1["apiserver..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 06. secrets management
Kubernetes의 Secret은 "비밀"이 아니다 — 그럼 진짜 비밀은 어디에 두나config-secret 에서 Secret이 base64 인코딩일 뿐 "비밀"이 아니라고 했다. etcd엔 사실상 평문. RBAC으로 읽기 권한 있으면 그냥 본다. 그렇다면 진짜 비밀(DB 비밀번호, API 키)은 어디에 어떻게 두나? 한 팀이 이 질문에 답하며 거칠게 세 가지를 시도했다 — etcd 암호화, Vault 연동, 그리고 External Secrets Operator. 이 글은 그 답들을 정리한다.이 글이 푸는 것은: Kubernetes Secret의 보안 한계를 극복하는 세 접근(etcd 저장 암호화, 외부 비밀 저장소 연동, Gitops 친화적 sealed-secrets)이다.Secret의 두 한계 — ..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 05. pod-security-admission
"privileged: true"가 왜 기본으로 허용되는가 — Pod Security Admission과 PSP의 역사한 팀이 보안 점검에서 지적받았다: 클러스터의 Pod 중 일부가 privileged: true로 돌고 있었다 — 컨테이너가 노드의 커널·장치에 직접 접근할 수 있는 위험 모드. "이걸 막는 기능이 있지 않았나?" 있었다 — PodSecurityPolicy(PSP). 그런데 Kubernetes 1.25에서 PSP는 제거됐다. 후속이 Pod Security Admission. 왜 바뀌었고, 새 모델은 어떻게 다른가?이 글이 푸는 것은: Pod의 권한 상승을 통제하는 Pod Security Admission의 세 모드(privileged/baseline/restricted), 그리고 PSP가 ..