[CKS] RBAC 설정

 

 

RBAC(Role-Based Access Control) 이란?

사용자 또는 서비스에 대한 액세스 권한을 관리하기 위한 보안 모델 중 하나입니다. 이 모델은 사용자가 시스템 내에서 수행할 수 있는 작업을 정의하기 위해 역할이라는 개념을 사용합니다. 이는 특정 역할에 대한 권한이 부여되고, 해당 역할이 사용자 또는 그룹에 할당됨으로써 사용자가 권한을 얻게 됩니다.

 

 

<참고>

IRSA (IAM Role for Service Accounts) 란?

이는 AWS EKS에서 Kubernetes Service Account와 AWS IAM Role을 연결하여 AWS 리소스에 대한 접근을 관리하는 메커니즘을 의미합니다.

IRSA는 IAM(Role)과 Kubernetes Service Account를 매핑하여, Pod나 Deployment 등의 Kubernetes 리소스가 AWS 서비스와 상호 작용할 때 AWS 리소스에 대한 권한을 제공합니다. 기존에는 Kubernetes Pod 내에서 AWS SDK를 사용하여 AWS 리소스에 액세스하기 위해 IAM 인증 정보를 하드 코딩하여 사용했습니다. 하지만 이는 보안상의 이슈를 야기할 수 있었습니다.

 

구성요소

1. 사용자 계정 (ServiceAccount)

쿠버네티스 클러스터 내에서 실행되는 워크로드에 사용되는 계정입니다. (Service Account)

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubernetes.io/enforce-mountable-secrets: "true"
  name: my-serviceaccount
  namespace: my-namespace

 

만약 빠르게 생성하고 싶다면 kubectl 명령어로 바로 생성이 가능합니다.

$ kubectl create serviceaccount my-serviceaccount -n my-namespace
$ kubectl create sa my-serviceaccount -n my-namespace

 

2. 역할

역할은 크게 Role (namespace 단위)와 ClusterRole(cluster 단위)로 구분됩니다. 만약 특정 네임스페이스에 역할을 부여하고 싶다면 role을 사용하고, 클러스터 전체에 대한 역할이 필요하다면 clusterRole을 사용합니다. 여기에서도 알 수 있듯 시스템 전반에 해당하는 서비스가 아니라면 반드시 role을 사용하는게 접근통제의 원칙에 알맞습니다.

 

Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # ""는 코어 API 그룹을 나타냅니다.
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

 

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 필드는 clusterrole에서 사용하지 않습니다. 어짜피 전체 네임스페이스 대상입니다.
  name: secret-reader
rules:
- apiGroups: [""]
  # HTTP 수준에서 secrets의 리소스 이름은 secrets 입니다. 쿠버네티스에서 사용하는 리소스 이름을 차용합니다.
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

 

 

 

3. 바인딩(연결)

쿠버네티스 상에서 사용할 사용자 계정과 역할을 각각 매핑하는 작업을 해줘야 해당 사용자에게 역할이 부여됩니다. 당연히 일반 role은 rolebinding을 사용하고 clusterRole은 clusterRoleBinding을 사용해야 합니다.

 

Rolebinding

아래  yaml은 "jane" 이라는 serviceaccount가 default 네임스페이스에서 pod를 read할 수 있는 권한입니다. 당연히 default 네임스페이스에는 "pod-reader"라는 역할이 이미 존재해야합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 

ClusterRoleBinding

아래 yaml은 manager라는 serviceaccount가 클러스터의 모든 secret을 읽을 수 있는 내용입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

 

 

4. can-i로 권한 확인

can-i를 통해서 kubectl로 접근하는 사용자가 어떤 권한이 있는지 yes/no로 확인할 수 있습니다.

kubectl auth can-i create deployments --namespace prod

 

만약 특정 serviceaccount에 대한 권한을 확인하고 싶다면 다음과 같이 입력합니다.

여기서 dev는 네임스페이스이며, dev-sa는 서비스 어카운트 입니다.

kubectl auth can-i list pods \
	--namespace target \
	--as system:serviceaccount:dev:dev-sa