N° 01 — 목록
'Cloud & Infrastructure/Kubernetes Security' (10)
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 04. admission-control
인증·인가 통과한 뒤에도 한 번 더 검문한다 — 어드미션 컨트롤한 팀이 "모든 Pod는 반드시 자원 제한(limits)을 가져야 한다"는 정책을 원했다. RBAC는 "누가 만들 수 있나"만 다루지 "만들어지는 객체가 어떤 모양*이어야 하나"는 다루지 못한다. 그래서 그 팀은 Pod를 만들고 *나서 수동으로 검사했다 — 늦었다. 어드미션 컨트롤(Admission Control)이 이 빈 칸을 채운다 — 인가 통과 후, 객체가 etcd에 저장되기 전에 한 번 더 검문한다.이 글이 푸는 것은: 어드미션 컨트롤이 인증·인가 뒤에 무엇을 검사하는가, 그리고 ValidatingAdmissionPolicy(CEL 기반, 1.30 GA)가 정책 코드를 어떻게 바꿨는가다.요청의 네 단계 — 어드미션은 세 번째flowch..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 03. fine-grained kubelet API authorization
Pod 목록을 읽으려면 exec 권한이 필요했다 — fine-grained kubelet API authorizationPrometheus가 노드의 Pod 목록을 수집하려 한다. 노드에 들어가 kubectl이 보는 것과 비슷한 정보를 얻으려면, kubelet이 10250 포트에 연 HTTPS API를 호출해야 한다. 그런데 1.32 이전의 kubelet에서 /pods를 읽으려면 RBAC상 nodes/proxy 권한이 필요했다. 문제는 이 nodes/proxy가 /pods(읽기)뿐 아니라 /exec/...(컨테이너 안에서 임의 명령 실행)를 인가하는 같은 권한이라는 점이다. 모니터링 에이전트가 Pod 개수를 세려다 노드 전체에 셸을 띄울 수 있는 능력을 함께 받은 셈이다.이 글은 kubelet API의 읽..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 02. authentication
"누구인가"를 증명하는 세 가지 방법 — Kubernetes 인증의 지형한 클러스터에 세 종류의 접속자가 있었다: 운영자(사람), CI/CD 파이프라인(자동화), 그리고 Pod 안의 앱. 셋 다 apiserver에 접근하지만 증명 방식이 달랐다 — 운영자는 회사 SSO(OIDC), CI는 서비스 계정 토큰, 앱은 마운트된 토큰. Kubernetes는 이 셋을 다른 방식으로 식별한다. "인증"이 하나가 아니라는 것을 모르면, 접속이 안 되는 이유를 엉뚱한 곳에서 찾는다.이 글이 푸는 것은: Kubernetes가 "누구인가"를 증명받는 여러 방식(X.509, OIDC, Service Account token)과 그 차이다. 특히 왜 세 방식이 다른가 — 접속자의 성격(사람/자동화/시스템)이 방식을 결정한다는..
-
Cloud & Infrastructure/Kubernetes SecurityK8s Security - 01. rbac
"누가 무엇을 할 수 있는가" — RBAC가 결정하는 권한의 단위한 클러스터에서 서비스 계정 하나가 모든 namespace의 Secret을 읽을 수 있었다. 개발자가 편하려고 ClusterAdmin을 줬기 때문이다. 그 서비스 계정이 탈취됐을 때, 공격자는 클러스터 전체의 비밀을 한 번에 들냈다. 이 사고의 원인은 RBAC의 오용이었다 — "편의를 위해 최대 권한"이 곧 "침해 시 최대 피해"가 된다.이 글이 푸는 것은: Kubernetes RBAC(Role-Based Access Control)이 "누가 무엇을 할 수 있는가"를 어떻게 결정하고, 최소 권한 원칙을 어떻게 실천하는가다. 03-k8s-security 영역의 출발점이자, 보안의 첫 번째 축이다.권한 제어의 세 축 — 누가, 무엇을, 어디서"..