[쿠버네티스 인 액션] 쿠버네티스 API 서버 보안

쿠버네티스 인 액션 12장을 참조하여 작성중입니다.
계속 작성하면서 업데이트 됩니다

 

 

인증

API 서버는 하나 이상의 인증 플러그인으로 구성됩니다.

API 서버는 요청을 받으면 인증 플러그인 목록을 거치면서 요청이 전달되고

각각의 인증 플러그인이 요청을 검사해서 보낸 사람이 누구인지 밝혀내려 시도합니다.

 

플러그인은 사용자 이름, 사용자ID, 클라이언트가 속한 그룹을 API 서버 코어에 반환합니다.

인증플러그인은 아래와 같습니다.

 

인증플러그인

• 클라이언트 인증서 (x.509)
  • ca인증서, 사용자인증서, 개인키
• HTTP 헤더로 전달된 인증토큰 (Bearer Token)
  • ex. curl -H "Authorization : <TOKEN> https://API요청
• 기본 HTTP 인증 (거의사용X)
• 기타
  • OIDC (Open ID Connect) : google, Azure AD
  • webhook Token Authentication

 

컴포넌트 간 TLS 통신

쿠버네티스 구성요소 간에도 apiserver와 TLS 통신을 진행합니다.

 

목적	위치	사용하는 컴포넌트
API Server 서버 인증서 (TLS 서버)	/etc/kubernetes/pki/apiserver.crt	모든 클라이언트 접근 대상
API Server → etcd 인증서	/etc/kubernetes/pki/apiserver-etcd-client.crt	API Server
API Server → kubelet 인증서	/etc/kubernetes/pki/apiserver-kubelet-client.crt	API Server
kubelet → API Server 인증서	/var/lib/kubelet/pki/kubelet-client-current.pem	kubelet
사용자 인증서	~/.kube/config	kubectl
controller-manager	/etc/kubernetes/controller-manager.conf 내 cert	API Server 접속용 client cert
scheduler	/etc/kubernetes/scheduler.conf 내 cert	API Server 접속용 client cert

 

인증 이후에는 kube apiserver는 인가과정을 진행합니다.

컴포넌트들도 RBAC 정책에 따라 권한을 부여합니다.

컴포넌트	ClusterRole	ClusterRoleBinding
kube-controller-manager	system:kube-controller-manager	system:kube-controller-manager
kube-scheduler	system:kube-scheduler	system:kube-scheduler
kubelet	system:node	system:node (그룹 system:nodes)
kube-proxy	system:node-proxier	system:node-proxier
coredns	system:coredns or 커스텀	보통 system:coredns 또는 ServiceAccount 바인딩
사용자 (kubectl)	보통 수동으로 생성된 Role/ClusterRole	사용자에 맞게 RBAC 수동 설정

 

kubectl get clusterrole

 

 

이후 API 요청을 보낼 때 어드미션 컨트롤러(Admission Controller) 과정을 거칩니다.

MutatingAdmissionWebhook -> ValidatingAdmissionWebhook -> etcd 저장 

 

 

MutatingAdmissionWebhook

요청을 받고 자동으로 값을 추가하거나 수정

• Istio, Linkerd 등에서 sidecar 주입
• 특정 라벨 자동 추가
• 기본 annotation 주입

예시)

1. 사용자의 pod 생성요청

2. API Server → Mutating Webhook 호출

3. Webhook이 Pod spec을 수정하여 반환합니다.

4. 변경된 Pod spec이 이후 처리됨 (인가, 저장 등)

 

 

ValidatingAdmissionWebhook

요청이 정책에 위배되는지를 검사하고, 허용/거부 판단만 함

• Pod이 root user로 실행되는지 검증
• 서비스에 필수 라벨이 없는 경우 거부
• 보안 정책 위반(PodSecurityPolicy-like)

예시)

1. 사용자 또는 컴포넌트가 리소스 생성/변경 요청
2. API Server → Validating Webhook 호출
3. Webhook이 허용/거부 응답
4. 거부되면 API 요청 실패 (400, 403)

 

아래와 같이 kube-apiserver 설정에서 확인이 가능합니다.

### 테스트환경 
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep enable-admission-plugins

 

NodeRestriction은 Validating 타입으로

kubelet이 자신이 관리하는 노드의 리소스만 수정 가능하도록 제한