Kubernetes 인증(authentication), 인가(authorization) 그리고 어드미션 컨트롤(admission control ) 에 대한 이야기 + serviceaccount

내가 준비했었던 CKA의 연습문제 그리고 실제시험에는 다음과 같은 유형의 문제가 나온다.  이 글에서는 이 문제를 해결하면서 쿠버네티스의 인증에 대해서 풀어볼 것이다.

Create a new user called john. Grant him access to the cluster. John should have permission to create, list, get, update and delete pods in the development namespace . The private key exists in the location: /root/CKA/john.key and csr at /root/CKA/john.csr. Important Note: As of kubernetes 1.19, the CertificateSigningRequest object expects a signerName. Please refer the documentation to see an example. The documentation tab is available at the top right of terminal.

문제를 분석해 보자면

(1) Create a new user called john

(2) Grant him access to the cluster

(3) John should have permission to create, list, get, update and delete pods in the development namespace

이렇게 3가지를 하라는 이야기이다.

 

Certificate Signing Requests

(1)번을 해결하기 위해서는 CSR 이라고도 불리는 certicate siging requests 에 대해서 알아야 한다. 

쿠버네티스 문서에는 CSR에 대해서 이렇게 설명하고 있다.

CSR 리소스는 지정된 서명자가 인증서에 서명하도록 요청하는데 사용되고, 최종적으로 서명되기전에 요청은 승인되거나 거부될 수 있다

이 CSR 문서를 통하여 실제 인증서가 생성된다는 것이다. 다시 (1)을 보면 John이라는 user을 만들으라고 한다. 쿠버네티스에는 사람에 대응하는 오브젝트가 없다. 따라서 user 또는 group으로 사용자를 정할 수 있다. 여기서 user는 수많은 쿠버네티스 오브젝트 중 하나가 아니고, 외부 인증에 관련이 있다. 또한  group도 그 user가 속한 서비스라고 생각하면 된다. 예를 들어 group엔 argocd나 gitlab, 그리고 user엔 argocd나 gitlab을 이용하는 user인 John이 해당한다고 할 수 있다. 

그런데 user를 만드는데 왜 csr이 필요한 것일까? John은 알다싶이 쿠버네티스 내부가 아닌 외부의 별도의 인증 시스템에 속해져 있는데, 이 user를 쿠버네티스에 인증하기 위해서이다. 그래서 우리는 John의 인증서를 쿠버네티스에서 인증받고 그 인증서를 만들어야 하는 것이다. 

 

이 그림은 쿠버네티스의 접근제어 체계 순서를 나타낸 것인데, 여기서 " 인증"에 관한 절차가 csr을 생성하고 쿠버네티스 관리자에게 허가를 받는 것이다. 

 

CSR을 만드는 방법은 다음과 같다. 

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: john
spec:
  request: $(cat /root/CKA/john.csr | base64 | tr -d "\n")
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

spec을 보면 여기서는 john의 인증서를 불러와 requst 하고 usage는 client auth 라는 것을 알 수 있다.

이렇게 john의 인증서요청이 들어오면 클러스터 매니저는 아래의 명령어로 이 CSR을 승인한다.(거부할 수도 있다)

이 과정이 문제의 (2)번 과정이다.

kubectl certificate approve john

이렇게 쿠버네티스에서 john을 인증했다.

 

마지막 (3)번 과정은 쿠버네티스의 접근제어 체계 순서에서 두번째인 인가이다.

이제는 role, rolebinding, clusterrole, clusterrolebinding이라는 쿠버네티스 오브젝트를 알아야 한다.

 

(cluster)role

role: 특정 네임스페이스 내에서 권한을 설정한다. 그러므로 네임스페이스를 지정하는 것이 필수

clusterrole: 네임스페이스가 없는 리소스. 각가의 네임스페이스에 권한을 관리하거나 클러스터 전역의 권한을 관리

 

(cluster)rolebinding

rolebinding: user와 role을 바인딩(=결합)한다. 한마디로 user에 role이라는 권한을 부여하는 것이다. 당연히 특정 네임스페이스 내의 권한만 부여한다.

clusterrolebinding: 클러스터 전역의 user와 role을 바인딩

 

 

(3)은 john에게 특정 네임스페이스인 development 내에서의 pod에 대한 여러 권한을 부여하라고 나온다. 위에서 정리했듯이 우리는 role과  rolebinding을 사용하면 될 것이다.

 

 

먼저 role이다. (yaml로도 관리 가능)

kubectl create role developer --resource=pods --verb=create,list,get,update,delete --namespace=development

그리고 rolebinding 이다.

kubectl create rolebinding developer-role-binding --role=developer --user=john --namespace=development

 

 

이렇게 하면 위의 문제는 해결했다. 나머지 궁금은 마지막 순서인 admission contol은 무엇인지와 serviceaccount 는 어떨때 쓰이는지까지 살짝 정리해본다.

 

admission control

공식문서: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

어드미션 컨트롤은 인증&인가 후 추가적인 요청 내용에 대한 검증이나 요청 내용을 변경할 때 사용한다. admission controller는 kube-apiserver에 컴파일 되어 있으며 클러스터의 관리자만 구성할 수 있다.  admission controller는 webhook으로 사용자에게 API가 열려 있으며 custom으로 구현할 수도 있다.(Dynamic Admission Controller)

Dynamic Admission Controller

- MutatingAdmissionWebhook - ValidatingAdmissionWebhook

 

ServiceAccount

만약 쿠버네티스 외부에 별도의 인증 시스템(=외부계정)을 구축해 놓았다면 OAuth (Open ID Connect)로 서드파티에 인증을 위임하는 기능을 제공한다. 외부의 인증 시스템을 그대로 쿠버네티스로 가져올 수 있는 것이다. 이때는 Guard, Dex같은 서드 파티에 인증을 위임하기 위한 도구를 사용하여 외부의 인증 시스템을 쿠버네티스와 연결해야 한다.

위의 문단은 실제 이용자인 사람을 인증하는 것이다. 반면  serviceaccount는 쿠버네티스의 자체 인증 기능중 하나(나머지 하나는 인증서) 로, 시스템(클라이언트, 콘솔 등)이 쿠버네티스 API에 접근하고자 할때의 권한이다. 이 Serviceaccount를 생성하면 자동적으로 secret이 생성되고, 이를 이용해 다양한 인증방식을 사용할 수 있다.

• Basic HTTP Auth
• Access token via HTTP Header
• Client cert
• CUstom made