RBAC (2) 썸네일형 리스트형 [Kubernetes] Control Plane - Kube Api Server 한 줄 요약: 쿠버네티스에서 무언가를 바꾸는 유일한 방법은 API 서버에 HTTP 요청을 보내는 것이다. 위 그림의 핵심위 아키텍처 그림을 보면 스케줄러와 컨트롤러 매니저, 그리고 워커 노드의 kubelet 사이에는 직접 연결된 선이 없다. 모든 선은 가운데의 kube-api-server 상자를 거친다. etcd로 들어가는 선도 오직 API 서버에서만 나온다. api-server 를 통하는 것은 쿠버네티스 설계의 핵심 그 자체다. 쿠버네티스는 컴포넌트들이 서로를 호출하며 협업하는 시스템이 아니다. 모든 컴포넌트는 오직 API 서버만 바라보고, 서로의 존재조차 모른다. 스케줄러는 kubelet에게 "이 파드 좀 띄워줘"라고 말하지 않는다. 그냥 API 서버에 있는 파드 객체에 nodeName: node-.. [Zero Trust - IAM] RBAC의 구조적 한계와 ABAC·ReBAC의 설계 차이 Alice는 마케팅팀 소속 직원이다. 오늘 새벽 3시, 브라질 IP에서 접속했다. 지난주에 피싱 메일을 클릭한 이력이 있다. 이 사람에게 고객 데이터 CSV 다운로드를 허용해야 하는가? 대부분의 시스템은 이 질문에 대답하지 못한다. "Alice는 마케팅팀 역할을 갖고 있고, 마케팅팀은 고객 데이터에 접근할 수 있다"는 사실만 알 뿐이다. 새벽 3시라는 사실도, 브라질 IP라는 사실도, 피싱 클릭 이력도 접근 결정에 개입하지 않는다. 이것이 Role-Based Access Control(RBAC)의 한계이고, 이 한계를 메우려는 시도가 ABAC, ReBAC로 이어진 흐름이다. 각 모델은 "접근을 어떻게 결정할 것인가"라는 질문에 서로 다른 방식으로 대답한다.RBAC — 역할이라는 단순한 약속RBAC가 등장.. 이전 1 다음