K8s API 접근제어

1 개요[ | ]

k8s API Access Control
k8s API 접근 제어
  • 쿠버네티스 API 서버(kube-apiserver)는 클러스터 요청의 진입점이다.
  • 요청은 여러 단계의 보안 검증·통제를 거쳐야만 etcd에 반영된다.
  • 접근 제어는 크게 인증(Authentication), 인가(Authorization), 어드미션 컨트롤(Admission Control)로 이루어진다.

2 처리 단계[ | ]

단계 설명 대표 메커니즘/예시 실패 시 결과
인증 요청자가 누구인지 확인한다. HTTP 헤더, 토큰, 클라이언트 인증서(TLS Client Authentication) 등을 활용하며, 여러 인증 모듈을 순차적으로 시도할 수 있다. X.509 클라이언트 인증서, OIDC, 서비스어카운트 토큰, 부트스트랩 토큰 401 Unauthorized
인가 인증된 주체가 요청한 동작을 수행할 권한이 있는지 확인한다. 여러 인가 모듈을 순서대로 평가하며, 하나라도 허용하면 통과된다. RBAC, ABAC, Node Authorizer, Webhook Authorizer 403 Forbidden
어드미션 컨트롤 etcd에 반영되기 직전 요청 객체를 최종 검증·(필요 시)수정하는 단계. 생성(create)·수정(update)·삭제(delete)·연결(connect: exec/attach/portforward/proxy) 요청에 적용되며, 단순 조회(get/list/watch)에는 적용되지 않는다. ValidatingAdmissionWebhook, ValidatingAdmissionPolicy, MutatingAdmissionWebhook[1], ResourceQuota, LimitRanger, PodSecurity 요청 거부 (보통 400/Invalid, 경우에 따라 403)
  • 접근 제어는 인증 → 인가 → 어드미션 컨트롤 순서로 진행된다.
  • 어드미션 컨트롤은 단순 승인/거부뿐 아니라, 요청 객체를 수정(mutating)할 수도 있다.
  • 이 과정을 모두 통과해야만 요청이 etcd에 기록되어 실제 클러스터 리소스로 반영된다.

Access-control-overview.svg

3 관련 기능[ | ]

감사(auditing)
  • 접근 제어는 아니지만, API 요청의 전 과정을 기록하는 기능이다.
  • 사용자, 애플리케이션, 컨트롤 플레인 동작을 추적하여 보안 분석·규제 준수를 지원한다.
  • 감사 정책을 통해 기록할 이벤트와 수준(Metadata, Request, RequestResponse 등)을 설정할 수 있다.

4 같이 보기[ | ]

5 참고[ | ]

  1. Mutating은 요청 객체를 수정만 하고 정책적 거부는 하지 않으므로 엄밀히는 접근 제어에 해당하지 않는다.
문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}