🔐 Kubernetes 권한 관리 (Authorization)
✅ 인증과 권한의 차이
- **인증(Authentication)**은 누가 접근했는지를 확인하는 절차
- **권한(Authorization)**은 무엇을 할 수 있는지를 제한하는 정책
- 사용자가 인증을 통해 클러스터에 접근한 후, 허용된 작업 범위를 결정하는 것이 권한 관리의 핵심
🎯 왜 권한 관리가 필요한가?
- 관리자 계정은 클러스터 내 모든 리소스에 대한 읽기/쓰기/삭제 권한 보유
- 조직 내 다양한 역할 (개발자, 테스터, CI/CD 시스템 등)이 접근할 경우 역할별 최소 권한 원칙 적용 필요
- 네임스페이스 기반 격리를 통해 팀별 또는 조직별 자원 분리 가능
- 서비스 계정은 외부 애플리케이션에 최소 권한만 부여
🔐 Kubernetes의 권한 부여(Authorization) 방식
🧠 Node Authorizer
- 내부 통신을 위한 kubelet 요청 처리 권한자
system:node:* 접두사가 붙은 사용자 이름과 system:nodes 그룹에 속한 경우 인증
- kubelet은 노드 상태 보고, 파드 정보 조회 등을 위해 API 서버에 접근
- 이러한 요청은 Node Authorizer에 의해 허용
⚙️ Attribute-Based Access Control (ABAC)
- 사용자 또는 그룹별로 정적 정책 파일을 생성하고 API 서버에 전달
- 정책 파일은 JSON 형식으로 구성
- 보안 변경 시 파일 수동 수정 및 API 서버 재시작 필요
- 운영 시 유연성과 유지보수에 불리한 방식
📄 예시 정책 파일 (ABAC)
[
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "dev-user",
"namespace": "*",
"resource": "pods",
"readonly": true
}
}
]
👥 Role-Based Access Control (RBAC)
- 역할(Role)을 중심으로 권한을 정의하고 사용자와 그룹에 할당
- 예: 개발자 그룹에 배포 권한만, 보안 팀에는 설정 변경 권한만 부여
- 사용자 권한 변경 시 Role만 수정하면 즉시 반영
- 운영에 표준화된 권한 관리 방식 제공
🌐 Webhook Authorizer
- 외부 권한 시스템과의 연동을 위한 방식
- 대표 도구: Open Policy Agent (OPA)
- API 서버가 사용자 요청 정보를 포함하여 외부 시스템에 전달
- 응답 결과에 따라 접근 허용 또는 거부 결정
- 정책 관리의 유연성과 외부 통합성 확보
🚫 AlwaysAllow / AlwaysDeny
- AlwaysAllow: 모든 요청 무조건 허용
- AlwaysDeny: 모든 요청 무조건 거부
- 디버깅 또는 테스트 환경에서만 제한적으로 사용 권장
🧩 Authorization Mode 설정 방법
- Kube API Server 실행 시 옵션으로 설정
--authorization-mode=Node,RBAC,Webhook
🧭 다중 권한 모드 동작 예시
- 사용자가 API 서버에 요청 전송
- 첫 번째 모듈 (예: Node Authorizer)이 거부
- 두 번째 모듈 (예: RBAC)이 허용
- RBAC에서 승인되었으므로 요청 수락 및 권한 부여 종료
📌 핵심 요약
- 인증은 "누구인지", 권한은 "무엇을 할 수 있는지"를 결정
- Kubernetes는 다양한 권한 시스템을 지원하며 RBAC이 가장 일반적
- Node Authorizer: 내부 kubelet 요청 처리
- ABAC: JSON 기반 정책, 유지보수 어려움
- RBAC: 표준 방식, 역할 중심의 유연한 권한 설정
- Webhook: 외부 정책 엔진 연동 가능
- Authorization Mode는 API 서버의 실행 옵션으로 설정