role & rolebinding / clusterRole & clusterRolebinding / service account

Introduction

role과 rolebinding에 대해서 개념을 잡고가기 위해 최대한 간추려서 써봄

---

 

Summary

• user와 role은 연결되기 위해 rolebinding이라는 리소스를 만듦
• role과 clusterrole차이는 namespace차이
• service account는 pod같은 리소스에 권한을 줄수있는 서비스계정? 임
• role만드는 커맨드는 verb와 resource필수
• rolebinding만드는 커맨드는 role과 user or serviceaccount필수
• command | wc -l은 출력 줄 수. grep할때 또 옆에 달아주면 해당 단어 갯수 알려줌

export samp="--dry-run=client -o yaml"

export now="--force --grace-period 0"

 

$samp, $now붙은건 이 명령어로 약어만든거니까 주의

 

Kubectl Reference Docs

 

 

---

 

 

# 먼저 공식문서는 이렇다.

Using RBAC Authorization

여기서 role 검색하면 쭈르륵 나옴

 

# 개념 이해

이런식으로  role은 user와 roleBinding이라는 리소스로 연결된다.

pv와 pvc랑 비슷한 느낌인것 같음. 

다만 구조가 좀 다른게 pv - pvc는 pod에서 pvc를 갖다가 볼륨으로 쓰지만 얘네는 pod에서 권한 얻는거는 service account라는 개념이다. 그냥 단순히 연결하는 거라고 보면 됨

그냥 AWS IAM유저랑 역할만드는거랑 똑같다.

역할그룹도 있는데 이것도 똑같은듯?

때문에 롤을 하나 만들고 rolebinding을 수정해서 유저를 추가/삭제할수도 있고 rolebinding을 새로 만들어서 role을 재활용할수도 있을듯.

 

 

 

# user

certificate signing requests

여기 포스팅에선 생략하겠지만 난 로컬 클러스터에 이미 muzzi라는 user를 만들어놨다.

 

 

# role & rolebinding

먼저 커맨드라인부터~

kubectl create role pod-reader --verb=get,list,watch --resource=pods

얘가 role만드는 커맨드라인이고,

kubectl create rolebinding pod-reader --role=pod-reader --user=muzzi

얘가 rolebinding만드는 커맨드 라인이다.

 

role 커맨드는 resource의 pod에서 get,list,watch라는 권한이 있는 pod-reader이라는 role을 만든다는거고,

rolebinding 커맨드는 pod-reader이라는 roleBinding을 만드는데 pod-reader role과 muzzi라는 user를 연결시켜준다는거다.

 

 

야믈로 보자면,

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: muzzi
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

뭐 이렇게 생겼음.

 

 

# 실제로 테스트해보자면

role과 rolebinding을 만들었다.

 

현재는 admin 으로 context로 config되어있어서 아래 명령어들이 이상없이 됨

 

kubectl config use-context muzzi
kubectl get pods
kubectl get svc

무찌 유저로 접속하여 pod는 확인이 되지만, svc는 확인이 안된다.

pod-reader이라는 role은 pod에 대해 get,list,watch권한만 가지기 때문.

 

 

 

 

# cluster role & cluster rolebinding

커맨드로 만드는건

kubectl create clusterrole cl-pod-reader --verb=get,list,watch --resource=pods

kubectl create clusterrolebinding cl-pod-reader --clusterrole=cl-pod-reader --user=muzzi

걍 role과 차이는 cluster가 붙냐 안붙냐 차이이다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cl-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cl-read-pods
subjects:
- kind: User
  name: muzzi
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cl-pod-reader
  apiGroup: rbac.authorization.k8s.io

yaml형식도 비슷하다. 다만 중요한건 name space필드가 없다는점. 

cluster role은 네임스페이스에 국한되지 않고, 클러스터 컨텍스트 전체 네임스페이스에서 적용된다.

얘네는 네임스페이스도 없다

role resource를 가져와보면 현재 ns인 default것만 가져오고 옵션 --all-namespaces를 달아줘야 다 보인다.

 

하지만 clusterRole은 네임스페이스에 속해있지않아 그냥 전체껄 다 가져와준다.

wc -l옵션은 줄 수임

 

떄문에,

현재 cluster role이 바인딩되어있는 상태인 muzzi user에서는 

모든 ns의 pod들이 조회 가능하지만

 

cl-pod-reader 인 cluster role과 cluster role binding을 삭제하고 일반 pod-reader role과 role binding만 남게되면 아까 cluster role이 바인딩된 상태였던 muzzi유저는 전체 namespace에서 pod조회가 불가능하게 된다.

 

 

 

# service account

pod가 k8s클러스터에 접근할 권한을 줄때 사용한다. 컨트롤러도 줄 수 있긴한데 보통 pod에 주니까.. kube-system에 있는 여러 k8s구성 pod들도 이러한 service account 권한에 의해 관리된다.

 

얘는 이런식으로 pod가 service account를 품고 만들어질 수 있는데, 이 service account에 role을 rolebinding해주면 해당 pod의 권한을 줄 수 있다.

걍 AWS 역할만드는거랑 비슷한개념

 

 

 

# 직접만들고 확인해보자

kubectl create serviceaccount pod-viewer

pod-viewer이라는 service account를 만들어줬따.. 졸라 단순 ㅋㅋ

kubectl run testpod --image=nginx --serviceaccount=pod-viewer

testpod라는걸 대충 만들건데, 얘는 serviceaccount가 아까 만든 pod-viewer이다.

 

 

kubectl get pods testpod -o yaml|grep pod-viewer

 

service account필드에 pod-viewer이라는 service account 가 연결되어있다.

 

참고로 나도 자세히는 모르지만 service account는 pod내에서 토큰으로 인증관리를 한다.

그래서 describe에 토큰이 찍히나봄

 

이제 이 pod-viewer에 role을 만들어서 연결시켜주자

 

탭 졸라쳐서 더럽지만 암튼 연결됬음.

참고로 rolebinding만들떄 service account넣는데는 ns:sa이런식으로 쳐야하더라.

 

참고로 검토하는것도 할까했는데 CKA목적이라 좀 복잡해질것같고

 

pod에 접속해서 exec로 커맨드라인 쳐서 토큰정보 읽은다음, 이걸 k8s api서버에 curl쳐서 확인하더라.

아니면 단순하게 auth can-i명령어 치는건데,

kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<serviceaccount-name>

이거 쳐보니

졸라 쿨하게 yes/no로 대답해줌