Kubernetes 환경에서는 사용자가 요청한 모든 Resource를 바로 생성하지 않습니다.
API Server는 요청을 받은 후 여러 단계의 검증 과정을 거쳐 최종적으로 Resource를 저장합니다.
이 과정에서 보안 정책과 운영 규칙을 적용하는 기능이 Admission Control입니다.
예:
개발자 Pod 생성 요청
↓
Authentication 확인
↓
Authorization 확인
↓
Admission Control 검사
↓
허용
↓
Pod 생성
Admission Control은 Kubernetes Governance와 Security Architecture에서 매우 중요한 역할을 담당합니다.
| 구성 요소 | 역할 |
|---|---|
| Admission Controller | API 요청 검사 |
| Validating Webhook | 요청 검증 |
| Mutating Webhook | 요청 변경 |
| Policy Engine | 보안 정책 적용 |
| API Server | 최종 Resource 관리 |
Admission Control 구조를 이해하면 Kubernetes 환경에서 자동화된 보안 정책과 운영 표준화를 구축할 수 있습니다.
Kubernetes Admission Control이란?
Admission Control은 Kubernetes API 요청이 처리되는 과정에서 Resource 생성, 수정, 삭제 요청을 검사하는 기능입니다.
기본 흐름:
User
↓
kubectl apply
↓
API Server
↓
Authentication
↓
Authorization
↓
Admission Control
↓
etcd 저장Resource가 저장되기 전에 정책을 적용합니다.
Kubernetes Admission Control이 필요한 이유
대규모 Kubernetes 환경에서는 개발자가 직접 모든 보안 설정을 관리하기 어렵습니다.
예:
개발자 배포
↓
Privileged Container 실행
↓
Host 접근 위험
Admission Control을 이용하면 자동으로 차단할 수 있습니다.
Kubernetes Admission Controller 종류
대표 유형:
Validating Admission Controller
요청을 검사하고 허용 또는 거부합니다.
예:
Root Container 실행
↓
정책 위반
↓
배포 차단
Mutating Admission Controller
요청 내용을 자동 변경합니다.
예:
Pod 생성
↓
자동 Label 추가
↓
Resource Limit 자동 적용
Validating과 Mutating 차이
| 구분 | Validating | Mutating |
|---|---|---|
| 역할 | 검증 | 변경 |
| 결과 | 허용/차단 | 자동 수정 |
| 예 | 보안 검사 | Label 추가 |
둘을 함께 활용합니다.
Kubernetes Validating Webhook이란?
Validating Webhook은 Kubernetes 외부 Policy Engine과 연결하여 Resource를 검사하는 방식입니다.
구조:
Developer
↓
API Server
↓
Validating Webhook
↓
Policy Check
↓
Allow / Deny보안 정책 자동화를 구현합니다.
Kubernetes Mutating Webhook이란?
Mutating Webhook은 Resource 요청을 자동으로 수정합니다.
예:
Pod 생성 요청
↓
Sidecar Container 자동 추가
↓
Security Context 추가
↓
최종 생성
Service Mesh 환경에서도 활용됩니다.
Kubernetes Admission Webhook 동작 과정
순서:
- 사용자가 Resource 요청
- API Server 요청 수신
- Authentication 확인
- Authorization 확인
- Mutating Webhook 실행
- Validating Webhook 실행
- etcd 저장
정해진 순서대로 처리됩니다.
Kubernetes Policy Engine과 Admission Control
Policy Engine은 Admission Control과 함께 사용됩니다.
대표:
- OPA Gatekeeper
- Kyverno
구조:
Policy 작성
↓
Admission Webhook 연결
↓
Resource 검사
↓
허용 또는 차단
자동 보안 Governance를 구현합니다.
Kubernetes Admission Control 활용 사례
Security Context 강제
정책:
모든 Container
↓
Non-root 실행 필수
위반 시 배포 차단
Image Registry 제한
정책:
허용 Registry
↓
Private Image만 사용
Resource Limit 강제
정책:
CPU Limit 필수
Memory Limit 필수
운영 표준을 자동 적용합니다.
Kubernetes Admission Control과 GitOps
GitOps 환경에서는 Policy도 코드처럼 관리합니다.
구조:
Git Repository
↓
Policy YAML
↓
Argo CD
↓
Admission Control
↓
Cluster 적용
변경 이력을 관리할 수 있습니다.
Kubernetes Admission Control 보안 Best Practice
권장:
- Production 환경 Policy 적용
- Test 환경 검증 후 적용
- Webhook High Availability 구성
- Policy Version 관리
- Audit Log 활성화
잘못된 정책으로 인한 장애를 예방해야 합니다.
Kubernetes Admission Control 장애 분석
Webhook 확인:
kubectl get validatingwebhookconfigurationMutating 확인:
kubectl get mutatingwebhookconfiguration상세 확인:
kubectl describe validatingwebhookconfiguration name확인:
- Webhook Certificate 오류
- Policy 문법 오류
- API Server 연결 문제
- Timeout 발생
Kubernetes Admission Control 운영 전략
Production 환경:
보안 정책 정의
↓
Policy Engine 구성
↓
Webhook 연결
↓
Test 환경 검증
↓
Production 적용
↓
Monitoring
자동화된 Governance 환경을 구축합니다.
Kubernetes Admission Control 장점
| 장점 | 설명 |
|---|---|
| 자동 정책 적용 | 수동 검토 감소 |
| 보안 강화 | 위험 Resource 차단 |
| 표준화 | 운영 기준 유지 |
| Compliance 대응 | 감사 지원 |
Admission Control은 Kubernetes Enterprise 운영의 핵심 관리 기능입니다.
자주 묻는 질문
Admission Control은 RBAC와 같은 기능인가요?
아닙니다.
RBAC는 사용자의 권한을 관리하고 Admission Control은 Resource 생성 규칙을 관리합니다.
모든 Resource를 차단하는 것이 좋은가요?
아닙니다.
서비스 요구사항에 맞는 정책을 설계해야 합니다.
Webhook 장애가 발생하면 어떻게 되나요?
설정에 따라 Resource 생성이 차단되거나 정상 처리될 수 있으며 운영 환경에서는 High Availability 구성이 필요합니다.
마무리
Kubernetes Admission Control은 API Server 요청 과정에서 Resource를 검사하고 변경하여 보안 정책과 운영 기준을 자동 적용하는 핵심 Governance 기능입니다.
| 구성 요소 | 역할 |
|---|---|
| API Server | 요청 처리 |
| Mutating Webhook | 자동 변경 |
| Validating Webhook | 검증 및 차단 |
| Policy Engine | 보안 규칙 관리 |
| Audit Log | 변경 기록 |
Admission Control 구조를 이해하면 Kubernetes 환경에서 안전하고 자동화된 Enterprise 운영 정책을 구축할 수 있습니다.