[쿠버네티스] 클라이언트 유형별 API 서버 접근 방법 및 권한 관리 전략

Kubernetes는 클라이언트 유형에 따라 API 서버에 접근하는 방식이 다릅니다. 이번 포스팅에서는 유저와 포드(Pod)가 어떻게 Kubernetes API 서버에 접근하는지, 그리고 Kubernetes에서 권한을 안전하게 관리하는 방법에 대해 다룹니다.

클라이언트 유형별 API 서버 접근 방법

1. 유저

Kubernetes API 서버에 접근하는 사용자는 OIDC(OpenID Connect)나 IRSA(IAM Role Service Account) 같은 SSO(Single Sign-On) 시스템을 통해 인증을 받습니다.

• OIDC (OpenID Connect): 외부 인증 제공자(ex. 구글 워크스페이스, 옥타 등)를 통해 인증 후, OIDC 토큰을 API 서버로 전달하여 접근합니다.
• IRSA (IAM Roles for Service Accounts): AWS 환경에서 IAM 역할을 Kubernetes 서비스 어카운트와 연동하여 접근을 제어합니다. AWS IAM의 권한이 Kubernetes와 연동되어, 사용자에게 부여된 IAM 권한으로 API 서버 접근을 허용합니다.

2. 포드 (Pod)

포드 내부에서 실행되는 애플리케이션이 API 서버와 통신하기 위해서는 서비스 어카운트(Service Account)를 사용합니다. 포드는 일반 사용자와 달리 사람이 접근하는 형태가 아니기 때문에, 주로 JWT(JSON Web Token)를 기반으로 한 서비스 어카운트 토큰을 사용해 API 서버에 접근하게 됩니다.

• 서비스 어카운트: 특정 포드가 Kubernetes API 서버와 통신할 수 있도록 설정한 권한 계정입니다. 여러 포드가 하나의 서비스 어카운트를 사용할 수 있으며, 포드가 생성될 때 serviceAccountName을 지정해 사용하도록 합니다. 네임스페이스에 기본으로 생성되는 default 서비스 어카운트가 있지만, 별도의 권한이 없습니다.

 

서비스 어카운트 예제

아래와 같이 ServiceAccount 리소스를 생성하고, 이를 포드 매니페스트의 spec.serviceAccountName에 지정해 포드에 적용할 수 있습니다.

# 서비스 어카운트 매니페스트
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
---
# 포드 매니페스트
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot # Pod에 서비스 어카운트 지정
  ...

 

 

그룹과 권한 관리

그룹 (Group)

Kubernetes에서는 사용자와 서비스 어카운트를 그룹(Group)으로 묶어 관리할 수 있습니다. 이를 통해 특정 그룹 단위로 권한을 부여하여 일괄적인 접근 제어가 가능합니다.

• 예시: 운영팀 사용자와 모니터링 포드를 각각 ops-group과 monitor-group으로 그룹화하여 필요한 권한만을 할당할 수 있습니다.

 

RBAC(Role-Based Access Control) 플러그인

Kubernetes의 RBAC(Role-Based Access Control) 플러그인은 사용자가 클러스터에 접근할 수 있는 권한을 제어하는 핵심 요소입니다. RBAC는 다음의 리소스를 통해 관리됩니다.

1. 롤 (Role) 및 클러스터 롤 (ClusterRole):
   • 롤은 네임스페이스 내에서만 유효하지만, 클러스터 롤은 모든 네임스페이스와 클러스터 전체에서 사용 가능합니다.
   • 예를 들어, 네임스페이스 내부의 리소스를 관리하는 Role을 정의하거나, 클러스터 수준에서 노드와 같은 클러스터 자원을 관리하는 ClusterRole을 정의할 수 있습니다.
2. 롤 바인딩 (RoleBinding) 및 클러스터 롤 바인딩 (ClusterRoleBinding):
   • RoleBinding과 ClusterRoleBinding을 사용해 사용자나 서비스 어카운트에 역할을 부여합니다.
   • RoleBinding은 네임스페이스 단위로, ClusterRoleBinding은 클러스터 단위에서 역할을 참조할 수 있습니다.

 

 

RBAC 설정 예제

 

# 클러스터 롤
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

# 클러스터 롤 바인딩
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-global
subjects:
  - kind: User
    name: "john.doe"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 

인증 권한 현명하게 부여하기

각 포드와 사용자에게 맞는 권한을 부여하는 것은 보안상 매우 중요합니다. 다음은 Kubernetes에서 권한을 효과적으로 부여하기 위한 몇 가지 팁입니다.

• 포드에 맞는 특정 서비스 어카운트 생성: 각 포드의 기능에 맞는 서비스 어카운트를 생성하고, 불필요한 권한을 최소화합니다.
• 롤바인딩을 통한 맞춤형 권한 부여: 서비스 어카운트와 사용자 그룹을 네임스페이스별로 나누고, 그에 맞는 권한을 할당합니다.
• 클러스터 롤을 신중하게 사용: 클러스터 전체에 영향을 미치는 리소스에 대해서는 최소 권한의 원칙을 적용하여, 필요한 경우에만 클러스터 롤을 부여합니다.

결론

Kubernetes는 유연한 API 서버 접근 방식과 권한 관리 기능을 제공합니다. 특히 서비스 어카운트와 RBAC 설정을 통해 포드와 사용자의 API 서버 접근을 효과적으로 제어할 수 있습니다. Kubernetes에서 API 서버 접근 권한을 현명하게 관리하고자 한다면, RBAC와 서비스 어카운트의 역할을 이해하고, 필요한 최소 권한 원칙을 따르는 것이 중요합니다.