[Kubernetes] Service Account & Role

보편적으로 account라 하면, 해당 서비스에 접근하기 위한 유저의 계정을 생각한다.

그러나 kubernetes에서 account라 하면, 보편적으로는! service account를 의미한다고 보면 된다.

물론 일반적인 user account도 있지만, kubernetes는 그러한 유저 정보를 별도로 저장하지 않는다.

 - 단지 외부 서비스에 의한 인증(Oauth 등)을 제공만 할뿐, 별도로 저장해서 가지고있지 않다는 뜻.

 

그러면 service account란 뭘까.

 - 단순하게 말해서 kube에 접근하고자 하는 시스템의 계정이다.

 - 즉, kubernetes의 API를 이용해 kube를 수정하거나 조회하려면, 해당 시스템은 적절한 servica account를 가지고 있어야 한다는 것.

 - 생성은 복잡하지 않다 kubectl create sa(serviceaccount) 이름

 - 생성한 계정을 .kube/config에 입력해두면 master가 아닌곳에서도 kubectl을 이용해서 접근이 가능하다.

 - KUBE의 API에 접근할 때에도 이런 service account의 정보를 실어서 보내면 접근이 가능하다.

     - kubernetes dashboard에 접속할 때가 대표적인 예인데, 거기서는 bearer token을 입력하라고 한다.

     - 혹은 kubeconfig에 정보를 입력해서 토큰 대신 사용해도 된다. 

     - 해당 토큰은 kubectl describe 명령어로 확인할 수 있다.

 

 - 이러한 service account는 pod에도 지정해줄 수도 있음

 - 기본적으로 pod는 별다른 SA를 지정하지 않으면 default SA를 가지게 됨.

 

 

그렇다면 이 service account의 목적은?

 - 당연하게도 유저 인증. 거기에 role까지 붙이면 authentication과 authorization을 모두 달성할 수 있다!

 - 기본적으로 구성되어있는 role 외에도, kubernetes role을 직접 생성할 수 있다.

    - 해당 role에는 어떤 리소스에 접근 가능한지, 어떤 api를 호출할 수 있는지 등을 적어둘 수 있다.

 - 이후, RoleBinding을 이용해서 해당 role을 특정 service account에 연결할 수 있다.

    - 이러한 role은 크게 두 종류로, Role과 ClusterRole이 있다.

    - role은 특정 namespace에 대한 권한을 지정하고자 할 때 보통 사용된다.

    - clusterRole은 이름처럼 클러스터에 대한 role을 부여하기에 리소스를 포함한 시스템 전체에 대한 권한을 지정해 줄 수 있다.

 

 

아직 pod에 대해서는 이 SA와 role을 깊게 적용해보지는 않았다.

주로 타 네임스페이스의 리소스 접근이나 뭐 대쉬보드 생성 이럴 때 사용하긴했었는데, 좀 더 찾아보고 적용해봐야겠다.