N° 01 — 목록
'Kubernetes' (40)
-
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 영역의 출발점이자, 보안의 첫 번째 축이다.권한 제어의 세 축 — 누가, 무엇을, 어디서"..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 14. multi-cluster
클러스터 경계를 넘는 서비스 — 멀티클러스터 네트워킹의 두 접근한 조직이 리전별로 클러스터 3개(서울/도쿄/버지니아)를 운영한다. 각 클러스터는 독립적이다 — 그런데 "서울 클러스터의 서비스가 도쿄 클러스터의 서비스를 불러야 한다"는 요구가 생겼다. 인터넷 경유 공개 API로만 부르자니 지연과 보안이 문제다. 멀티클러스터 네트워킹이 이 문제를 푼다 — 클러스터 경계를 넘어 Pod가 마치 같은 클러스터에 있는 것처럼 통신하게.이 글이 푸는 것은: 클러스터 간 Pod/Service 통신을 어떻게 만드는가, Submariner와 Cilium Cluster Mesh 두 접근이 어떻게 다른가다. 02-k8s-networking 영역의 마지막 주제로, 규모가 커질 때의 네트워크 진화를 다룬다.왜 클러스터를 여러 개..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 13. troubleshooting
"네트워크가 안 된다"에서 시작해 범인을 좁히는 법 — 트러블슈팅 결정 트리한 서비스가 "DB에 연결이 안 된다"고 보고됐다. 운영자가 1시간을 헤맸다 — Pod가 살아있는지, Service가 있는지, NetworkPolicy가 막는지, CNI가 꼬였는지, DNS가 풀리는지 전부 의심했다. 결국 원인은 conntrack 테이블 만료. 그런데 그 1시간의 대부분은 틀린 층을 뒤진 데 쓰였다. 이 글은 그 1시간을 5분으로 줄이는 결정 트리를 다룬다.이 글이 푸는 것은: "네트워크가 안 된다"는 모호한 증상에서 시작해, 어느 층(DNS/kube-proxy/CNI/정책/커널)인지를 체계적으로 좁히는 절차다. 핵심은 층별로 나눠 한 층씩 검증하는 것이다.먼저 층을 나눈다 — 어디를 의심할 것인가지금까지 01~1..