소개

이번에는 RBAC의 동작을 확인하고 있으면, 유저 관리의 이야기가 되어 왔습니다.

자세하게 알고 싶은 분은, 이 기사보다 이하의 사쿠라 인터넷씨의 기사가 자세하게 해설되고 있으므로, 이쪽을 보시는 것이 낫습니다.

Kubernetes의 사용자 관리 및 인증 및 권한 확인 메커니즘을 이해합시다.

사용자 인증 설정

Kubernetes에서는 authentication 모듈이 표준으로 몇 개 제공되고 있습니다만, 이번은 「X509 Client Certs」를 사용합니다.

개인 키 만들기

개인 키 'user01.key'를 작성하고 서명 요청 파일 'user01.csr'을 작성하십시오.

$ openssl genrsa -out user01.key 2048
Generating RSA private key, 2048 bit long modulus
.....................................+++
.......................................................................+++
e is 65537 (0x10001)
$ openssl req -new -key user01.key -out user01.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:user01
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:user01
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

서명 파일 만들기

서명 파일 "user01.crt"를 만듭니다.

$ sudo openssl x509 -req -in user01.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out user01.crt -days 10000

Signature ok
subject=/C=XX/L=Default City/O=user01/CN=user01
Getting CA Private Key

$ ls
user01.crt  user01.csr  user01.key

인증서를 API 서버에 추가

작성한 인증서를 API 서버에 추가합니다.

$ kubectl config set-credentials user01 --client-certificate=user01.crt --client-key=user01.key --embed-certs=true
User "user01" set.

Context 설정

클러스터 이름과 기존 Context 확인

$ kubectl config get-clusters
NAME
kubernetes
$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin

Context 만들기

user01에 대한 Context를 만듭니다.

$ kubectl config set-context user01-context --user=user01 --cluster=kubernetes
Context "user01-context" created.
$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
          user01-context                kubernetes   user01

Context 전환

$ kubectl config use-context user01-context
Switched to context "user01-context".
$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
          kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
*         user01-context                kubernetes   user01

확인

현재 user01에 권한이 설정되지 않았으므로 kubectl 명령으로 오류가 발생했는지 확인합니다.

$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "user01" cannot list resource "pods" in API group "" in the namespace "default"

확인이 완료되면 원래 Context로 돌아갑니다.

$ kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

RBAC 설정

이전에 만든 user01에 대한 권한을 설정하려면 RBAC를 사용합니다.
RBAC에는 Role/RoleBinding과 ClusterRole/ClusterRoleBinding의 2가지가 있습니다. Role/RoleBinding은 Namespace 레벨, ClusterRole/ClusterRoleBinding은 Cluster 레벨과 설정 범위가 다릅니다.

Using RBAC 인증

ClusterRole/ClusterRoleBinding 설정

다음 매니페스트에서 모든 API 그룹의 모든 리소스에서 get/list/watch를 설정할 수 있습니다.

clusterRole.yaml

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: readonly-for-all
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["*"]
  verbs: ["get", "list", "watch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: readonly-for-test
subjects:
- kind: User
  name: user01
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: readonly-for-all
  apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f clusterRole.yaml
clusterrole.rbac.authorization.k8s.io/readonly-for-all created
clusterrolebinding.rbac.authorization.k8s.io/readonly-for-test created

설정 내용을 확인합니다.

$ kubectl describe clusterrole readonly-for-all
Name:         readonly-for-all
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"name":"readonly-for-all"},"rules":[{"apiGr...
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [get list watch]
             [*]                []              [get]
             [*]                []              [list]
             [*]                []              [watch]
$ kubectl describe clusterrolebinding readonly-for-test
Name:         readonly-for-test
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"readonly-for-test"},"roleRef...
Role:
  Kind:  ClusterRole
  Name:  readonly-for-all
Subjects:
  Kind  Name    Namespace
  ----  ----    ---------
  User  user01

동작 확인

Context를 전환하여 RBAC의 동작을 확인합니다.

$ kubectl config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
          user01-context                kubernetes   user01
$ kubectl config use-context user01-context
Switched to context "user01-context".
$ kubectl config current-context
user01-context

$ kubectl get pod
No resources found in default namespace.
$ kubectl apply -f nginx.yaml
Error from server (Forbidden): error when creating "nginx.yaml": pods is forbidden: User "user01" cannot create resource "pods" in API group "" in the namespace "example"

포드가 없지만 RBAC를 설정하기 전에 오류가 발생한 kubectl get pod 명령이 성공적으로 반환되었습니다.
또, Pod의 작성은 권한이 없기 때문에 실패하고 있군요.

요약

사용자 인증의 흐름은 다음과 같습니다. 이번 검증 환경은 온프레 환경이기 때문에 API 서버와 클라이언트가 동일한 노드가 됩니다.
그래서, 유저의 전환이 Context의 전환만이 되어 버리고 있어, OS의 유저는 변하고 있지 않습니다. 아마도 클라우드의 클러스터에 대해 클러스터 외부에서 액세스할 때 이 설정을 활용할 것입니다.


인용구 : Kubernetes의 사용자 관리 및 인증 및 권한 확인 메커니즘을 이해합시다.

RBAC 자체는 자원을 묶어 가면 좋고, Role이나 ClusterRole도 디폴트로 준비되어 있는 것도 있기 때문에, 알기 쉬울까라고 생각합니다.

P.S.
사쿠라 인터넷씨의 기사가 매우 공부가 되었습니다. 고마워요.