[kubernetes] Serviceaccount, context를 사용한 개발자 계정 생성

그 전 포스팅에서는 멀티 클러스터 및 kubectx, context를 다뤘다.

여기서 kubectx 및 context 얘기를 많이 할거여서 참고하면 이해하기 좋다

 

추가로 contex, serviceaccount, role를 사용해서 특정 contex에서 지정한 namespace만 동작하고 다른 namespace에서는 요청을 거부시키는 방법을 해본다.

예로 아래 같이 쿠버네티스 내부 개발팀을 위한 계정을 만들고 권한을 제한 할 때가 자주 사용한다.

 

Client의 쿠버네티스 요청은 kube-api를 통해 처리된다.

그 후 kube-api는 사용자 요청을 처리하기 전 Context를 확인하여 올바른 사용자가 맞는지 사용자의 신원을 확인하고(인증)  확인된 사용자에게 리소스에 액세스할 수 있는 권한을 부여됐는지(인가) 확인한다.

 

 

구성은 아래와 같다 

 

우선 dev라는 네임스페이스 생성

k create ns dev

 

생성했던 네임스페이스를 기반으로 context를 생성

k config set-context context이름 --cluster=클러스터이름 --namespace=사용할 네임스페이스 --user=사용할 user 이름
아래와 같이 구성
k config set-context dev --cluster=eks.ap-northeast-2.eksctl.io --namespace=dev --user=dev

 

아래와 같이 dev라는 context를 생성하고 dev로 이동하면 인증된 user가 없기 때문에 username과 password를 입력하라고 나오고 인증 인가 설정을 안했기 때문에 어떠한 명령어도 사용하지 못한다 

 

다시 원래 사용하던 context로 돌아온 후 dev context에 인증할 user=dev를 dev라는 namespace가 포함되게 serviceaccount를 생성해준다.

 

 

serviceaccount를 생성하면 자동으로 serviceaccount에 대한 secret이 생성되는데 describe 명령어를 통해 secret을 확인하면 토큰을 확인할 수 있다.

 

확인한 토큰을 좀 더 편하게 사용하기 위해 환경 변수로 설정 후 echo로 한번 출력 

export DEV_Token="토큰"
echo $DEV_Token

 

후 set-credentials --token 옵션을 사용하여 환경변수로 지정했던 변수를 user=dev에 토큰을 설정

k config set-credentials --token=토큰 context에넣었던user이름
아래와 같다
k config set-credentials --token=$DEV_Token dev

 

이제 다시 dev context로 다시 옮기고 get, run 명령어를 해보면 인증은 되었지만 인가가 되있지 않은 모습을 확인할 수 있다.

 

인가가 되어 있었지 않았기 때문에 생성했던 serviceaccount에 role, rolebinding을 사용하여 인가하면 아래와 같다

k create role 생성할role이름 --resource=역할을줄리소스 --verb=할당할 권한 -n 네임스페이스
k create rolebinding 생성할rolebinding이름 --serviceaccount= serviceaccount에 적용한 네임스페이스:  serviceaccount이름 --role=연결할 role 이름 -n 네임스페이스
 
k create role dev --resource=pods --verb=create,delete -n dev
k create rolebinding dev --serviceaccount=dev:dev --role=dev -n dev

아래 같이 help 명령어 시 디테일하게 설명해준다.
k create role --help
k create rolebinding --help

위처럼 제대로 생성된것을 확인하면 인가까지 끝난것이다

다시 dev context로 바꾼후 run이랑 get 명령어를 해보면 run 즉 create 명령어는 인가를 해줬기 때문에 작동하고 get 즉 list는 인가를 안해줬기 때문에 작동 되지 않는다. 

config 파일을 확인해서 dev context도 확인해보면 아래와 같이 생성된것을 확인 가능

 

참조

https://malwareanalysis.tistory.com/133