[Kubernetes] 보안 가이드 (Authentication & Authorization, RBAC)

☸️ Kubernetes 보안 개요 #

Kubernetes는 클러스터 기반 인프라이기 때문에 보안이 매우 중요합니다.
특히 다음 영역이 핵심입니다.

• 사용자 인증 (Authentication)
• 권한 인가 (Authorization)
• 네트워크 보안
• Secret 관리

이 글에서는 그 중에서도 사용자 인증과 권한 인가를 중심으로 정리합니다.

Authentication vs Authorization #

보안 시스템에서 가장 먼저 이해해야 하는 개념은 인증(Authentication) 과 인가(Authorization) 입니다.

예를 들어

로그인 → Authentication
권한 체크 → Authorization

Kubernetes 보안 구조 #

graph TD

A[Client]

B[Authentication]

C[Authorization]

D[Kubernetes API Server]

E[Cluster Resource]

A --> B
B --> C
C --> D
D --> E

흐름

1️⃣ Client 요청 2️⃣ 인증(Authentication) 3️⃣ 권한 확인(Authorization) 4️⃣ API Server 처리

Kubernetes 계정 종류 #

Kubernetes에서는 두 가지 계정을 사용합니다.

User Account #

일반적인 사용자 계정입니다.

특징

• Kubernetes 내부에서 직접 관리하지 않음
• 외부 인증 시스템과 연동

대표적인 인증 방식

• OAuth
• Webhook
• LDAP
• OIDC

Service Account #

Service Account는 Pod나 애플리케이션이 Kubernetes API를 사용할 때 사용하는 계정입니다.

예를 들어

• Controller
• Operator
• 내부 애플리케이션

ServiceAccount 생성 #

1kubectl create sa my-service-account

ServiceAccount 구조 #

graph TD

A[Pod]

B[ServiceAccount]

C[Secret Token]

D[Kubernetes API]

A --> B
B --> C
C --> D

ServiceAccount는 API 인증을 위한 Token을 Secret에 저장합니다.

Kubernetes 인증 방식 #

Kubernetes는 다양한 인증 방식을 지원합니다.

Bearer Token 인증 #

가장 많이 사용하는 방식입니다.

Authorization: Bearer {TOKEN}

ServiceAccount Token을 이용하여 API 호출이 가능합니다.

Token 조회 #

1kubectl describe sa default

또는

1kubectl describe secret {secret-name}

API 호출 예시 #

1curl https://APISERVER/api \
2 --header "Authorization: Bearer $TOKEN" \
3 --insecure

kubectl proxy를 이용한 인증 #

직접 Token을 사용하는 대신 kubectl proxy를 사용할 수도 있습니다.

1kubectl proxy --port=8080

이후 API 호출

curl localhost:8080/api

proxy가 자동으로 인증 정보를 추가합니다.

Authorization (권한 관리) #

인증 이후에는 권한 검사가 진행됩니다.

Kubernetes는 기본적으로 RBAC(Role Based Access Control) 을 사용합니다.

RBAC 구조 #

graph TD

A[User]

B[Group]

C[ServiceAccount]

D[Role]

E[RoleBinding]

F[Kubernetes Resource]

A --> E
B --> E
C --> E

E --> D
D --> F

핵심 구성

• Role
• RoleBinding
• ClusterRole
• ClusterRoleBinding

Role #

Role은 특정 리소스에 대한 권한 정의입니다.

예

• Pod 조회
• Deployment 생성
• Service 삭제

Role 예시 #

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: pod-reader
5
6rules:
7- apiGroups: [""]
8  resources: ["pods"]
9  verbs: ["get", "watch", "list"]

RoleBinding #

Role을 사용자 또는 서비스 계정에 연결합니다.

graph LR

A[User]

B[RoleBinding]

C[Role]

A --> B --> C

RoleBinding 예시 #

 1kind: RoleBinding
 2apiVersion: rbac.authorization.k8s.io/v1
 3
 4metadata:
 5  name: read-pods
 6
 7subjects:
 8- kind: User
 9  name: jane
10
11roleRef:
12  kind: Role
13  name: pod-reader
14  apiGroup: rbac.authorization.k8s.io

Role vs ClusterRole #

ClusterRole은 다음과 같은 리소스에 사용됩니다.

• Node
• PersistentVolume
• Cluster 설정

기본 제공 Role #

Kubernetes는 기본 Role을 제공합니다.

RBAC 전체 아키텍처 #

graph TD

A[User]

B[Group]

C[ServiceAccount]

D[Role]

E[ClusterRole]

F[RoleBinding]

G[ClusterRoleBinding]

H[Resource]

A --> F
B --> F
C --> F

F --> D
G --> E

D --> H
E --> H

ServiceAccount + RBAC 예제 #

먼저 ServiceAccount 생성

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: sa-viewer

ClusterRoleBinding 생성

 1kind: ClusterRoleBinding
 2apiVersion: rbac.authorization.k8s.io/v1
 3
 4metadata:
 5  name: default-view
 6
 7subjects:
 8- kind: ServiceAccount
 9  name: sa-viewer
10  namespace: default
11
12roleRef:
13  kind: ClusterRole
14  name: view
15  apiGroup: rbac.authorization.k8s.io

Pod에서 ServiceAccount 사용

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: pod-reader
 5
 6spec:
 7  serviceAccountName: sa-viewer
 8
 9  containers:
10  - name: reader
11    image: gcr.io/terrycho-sandbox/pod-reader:v1

이렇게 하면 Pod 내부에서 Kubernetes API를 호출할 수 있습니다.

정리 #

Kubernetes 보안 핵심

Authentication #

사용자를 식별

대표 방식

• Bearer Token
• Client Certificate
• OAuth

Authorization #

권한 관리

대표 방식

• RBAC

계정 종류 #