[Kubernetes] RBAC 설정 알아보기

---

안녕하세요. 오늘은 Kubernetes에서 RBAC 설정하는 것이 대해서 알아보고자 합니다. Kubernetes에서 RBAC는 클러스터단에서 혹은 네임스페이스 단에서 설정이 가능합니다. 네임스페이스단에서는 Pod를 설치하기 전에 Service Account를 생성하고 권한을 지정해서 설치하는 방법입니다. 클러스터단에서는 네임스페이스보다 한층 더 위에서 접근을 제어할 수 있는데요. 이번에는 클러스터단에서 제어하는 것에 대해서 알아보고자 합니다🤗🤗

예시를 위해서 저희는 크게 2가지의 역할로 나누어보려고 합니다. 첫번째 역할은 admin으로 모든 클러스터에 관리 및 접근이 가능합니다. 두번째 역할은 user로 모든 관리와 접근이 가능하지 않고 제약 조건들이 추가된 역할입니다. 기존에는 클라우드 환경 등을 이용해서 역할에 인증하는 부분들이 필요하지만, 현재는 클라우드 환경을 사용하지 않고  Linux의 유저를 대상으로 TLS 인증서를 발급하고 이에 권한을 다르게 주어서 제어해보겠습니다🎮

Linux User	Kubernetes Role	Path
root	admin	/root/workspace/rbac
test	user	/home/test/workspace/rbac

큰 틀로 확인해보면 이제 Linux에는 root와 test라는 계정이 있고 저희는 이에 따라서 Kubernetes Role을 각 Linux 유저에게 부여하게 됩니다. TLS 인증서 및 yaml 파일들은 해당 Linux 유저가 접근이 가능한 Path에 위치하게 됩니다. 

 

1. Admin 설정하기

1-1. 폴더 생성하기

cd /root/workspace
mkdir rbac
cd rbac
mkdir keys

•  root계정으로 접속한 후에 rbac 폴더에는 admin의 설정 파일을 저장하고 keys 폴더에는 amdin의 키를 저장합니다.

1-2. Admin 생성하기

설정을 위해서는 해당 Role과 이 Role의 내용을 Rolebinding과 연결을 진행해주어야합니다.

# admin_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-role
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

• `admin_role.yaml` 파일을 생성합니다.
• admin임으로 apiGroup, resource, verbs등의 제한을 두지 않고 진행합니다.
• resources :  pods, nodes, namespaces 등으로 제한이 가능합니다.
• verbs : get, list, watch, create등으로 제한이 가능합니다.

# admin_rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
  - kind: Group
    name: admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-role
  apiGroup: rbac.authorization.k8s.io

• `admin_rolebinding.yaml` 파일을 생성합니다.
• roleRef에 기존의 생성했던 Role을 부여해야합니다.

 

1-3. 설정 적용하기

kubectl apply -f /root/workspace/rbac/admin_role.yaml
kubectl apply -f /root/workspace/rbac/admin_rolebinding.yaml

• apply 명령어를 통해서 만들어준 Admin의 Role과 Rolebinding을 적용시켜줍니다.

 

1-4. Key 생성하기

cd /root/workspace/rbac/keys
openssl genrsa -out admin.key 2048
openssl req -new -key admin.key -out admin.csr -subj "/CN=admin/O=admin"
openssl x509 -req -in admin.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out admin.crt -days 365

• admin 계정에서 사용하기 위하여, TLS 인증서를 생성하여 keys 폴더에 넣어줍니다.

 

1-5. Key 적용하기

kubectl config set-credentials admin \
  --client-certificate=admin.crt \
  --client-key=admin.key
kubectl config set-context admin-context \
  --cluster=kubernetes \
  --user=admin

• 현재는 client-certificate, client-key의 위치가 /root/workspace/rbac/keys안에서 실행한다고 되어있을 때를 기준으로 작성되어있음으로 다른 위치에서 작성할 경우에는 해당 key의 위치를 확인 후 작성이 필요합니다.
• set-context 명령어 뒤에는 권한을 변경할 때 사용할 context의 이름을 지정할 수 있습니다.

 

1-6. 권한 부여하기

chown root:root /root/workspace/rbac/keys/admin.crt /root/workspace/rbac/keys/admin.key
chmod 600 /root/workspace/rbac/keys/admin.crt /root/workspace/rbac/keys/admin.key

• 마지막으로 권한을 부여해줍니다. test 계정에서는 root가 아님으로 해당 key에 대해서 접근이 불가함으로 admin의 역할을 사용할 수 없게 됩니다.

 

2. User 설정하기

2-1. 폴더 생성하기

cd /home/test/workspace
mkdir rbac
cd rbac
mkdir keys

• key를 생성하고 권한 설정을 하기 위해서는 root의 계정으로 진행해야함으로 user 역할은 test 계정이 받지만, root 계정으로 접속해서 설정을 진행해여야 합니다.
• rbac 폴더에는 user의 설정 파일을 keys 폴더에는 user의 키를 저장합니다.
• 해당 /home/test 폴더는 Linux의 권한을 줄 test 계정의 폴더임으로 원하는 유저로 할 경우에는 test를 해당 계정으로 변경해서 진행하면 됩니다.

 

2-2. User 설정하기

설정을 위해서는 해당 Role과 이 Role의 내용을 Rolebinding과 연결을 진행해주어야합니다.

# user_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-user-role
rules:
  - apiGroups: ["*"]
    resources: ["pods", "services", "namespaces", "nodes"]
    verbs: ["get", "list", "watch"]

• `user_role.yaml` 파일을 생성합니다.
• user에는 apiGroup, resource, verbs 등의 제한을 둡니다.
• resource는 pods, service, namespace, node만 확인이 가능하여, 명령어도 get, list, watch로 제한되어있습니다. 해당 역할에 포함되지 않은 resource와 명령어를 확인하려고 하는 경우에는 permission deined 에러가 발생하게 됩니다.

# user_rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-user-binding
subjects:
  - kind: Group
    name: user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-user-role
  apiGroup: rbac.authorization.k8s.io

• `user_rolebinding.yaml` 파일을 생성합니다.
• roleRef에 기존의 생성했던 Role을 부여합니다.

 

2-3. 설정 적용하기

kubectl apply -f /home/test/workspace/rbac/user_role.yaml
kubectl apply -f /home/test/workspace/rbac/user_rolebinding.yaml

• apply 명령어를 통해서 만들어준 Admin의 Role과 Rolebinding을 적용시켜줍니다.

 

2-4. Key 생성하기

cd /home/test/workspace/rbac/keys
openssl genrsa -out user.key 2048
openssl req -new -key user.key -out user.csr -subj "/CN=user/O=user"
openssl x509 -req -in user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out user.crt -days 365

• user 계정에서 사용하기 위하여, TLS 인증서를 생성하여 keys 폴더에 넣어줍니다.

 

2-5. Key 적용하기

kubectl config set-credentials user \
  --client-certificate=user.crt \
  --client-key=user.key
kubectl config set-context user-context \
  --cluster=kubernetes \
  --user=user

• 현재는 client-certificate, client-key의 위치가 /home/test/workspace/rbac/keys안에서 실행한다고 되어있을 때를 기준으로 작성되어있음으로 다른 위치에서 작성할 경우에는 해당 key의 위치를 확인 후 작성이 필요합니다.
• set-context 명령어 뒤에는 권한을 변경할 때 사용할 context의 이름을 지정할 수 있습니다.

 

2-6. 권한 부여하기

sudo mkdir -p /home/test/.kube
cp -i /root/.kube/config /home/test/.kube/
sudo chown -R test:test /home/test/.kube

• Kubernetes 설치는 보통 root 계정에서 진행함으로 kubectl 명령어를 사용할 수 있는 .kube 폴더가 없는 경우가 많습니다. 이러한 경우에는 test 계정에서도 kubectl 명령어를 사용할 수 있도록 root의 .kube 폴더를 복사해서 /home/test 안에 넣어주고 권한을 부여해줍니다.

chown -R test:test /home/test/workspace/rbac

• rbac 폴더의 권한이 현재는 폴더를 생성하고 작업을 진행한  root 계정으로 되어있음으로 test 계정이 접속할 수 있도록 test 계정의 권한을 부여합니다.

 

3. 권한 변경하기

kubectl config use-context admin-context
kubectl config use-context user-context

kubectl config use-context [context 이름]

• 명령어를 통해서 변경이 가능합니다. context 이름의 경우 key를 적용하면서 set-context 뒤에 지정한 이름입니다. 현재 저희는 admin에게는 admin-context라는 이름을 user에게는 user-context라는 이름을 지정했음으로 해당 이름을 적어서 사용하면 됩니다.
• admin-context의 경우에는, root의 폴더에 있음으로 root로 접속해야지만 모든 명령어를 사용할 수 있습니다. root의 경우에는 test 계정의 폴더에서 접속이 가능함으로 user 권한으로 변경이 가능하게 됩니다. user 권한으로 변경했지만, root니깐 모든 명령어랑 다 접근이 가능한 것은 아닙니다. user에서 제한했던 get, list, watch의 명령어만 가능하게 됩니다.
• test 계정의 경우에는 root의 폴더에는 애초에 접속이 불가함으로 권한을 변경해도 실행되지 않으며, 지정된 권한 이외의 명령어를 사용하게 되면 permission deined 에러가 발생하게 됩니다.
• 이렇게 Linux 계정에 따라서 Kubernetes 역할을 부여하여서 클러스터 단에서 권한을 제어할 수 있게 됩니다.

 

* 추가 명령어

# 현재 권한 확인
kubectl config current-context

# 권한 목록 확인
kubectl config get-contexts

# 권한 변경
kubectl config use-context user-context

 

---

끝이 안날 것 같은 회사 프로젝트가 드디어 마무리가 되었습니다. Kubernetes에 대해서 다룰 수 있는 정말 좋은 기회였습니다. 프로젝트 시작할 때에는 정말 아무것도 모르는 채로 시작하게 되었는데 현재는 Kubernetes에 대해서 많이 배울 수 있음에 감사하게 되었습니다. 다른 개발자분들도 아직 Kubernetes를 모르시는 분들이 계신다면 이전의 저와 같은 심정이었을 거라고 생각합니다. 너무 막막하고 어려워보이지만, 막상 하다보면 해낼 수 있고 알아갈 수 있는 좋은 기회인 것 같습니다. 이번 글도 이전의 저와 같이 고민하고 어려워하시던 분들에게 조금이나마 도움이 되기를 바랍니다!☺️😊