시골쥐의 공부생활

RBAC에서 Role은 어떻게 만들까?

오른쪽 yaml파일과 같이 Role에 대한 yaml파일을 만들고, kubectl create로 role을 생성해주면 된다.

rules에는 여러개의 key가 들어가서 여러 조건을 줄 수 있고, apiGroups은 coregroup일 경우 비워둔다.

role YAML을 다 작성하고 나서는? user - role간 link를 해준다.

즉, user를 role object와 linkg해주는 Role-binding이라는 yaml을 만든다.

(위 그림에서는 devuser-developer-binding.yaml)

subjects는 user에 대한 details를 작성하는 곳이고, roleRef는 생성된 role에 대한 정보를 작성하는 곳이다.

그리고 kubectl create -f devuser-developer-binding.yaml을 통해 binding object도 실행해준다.

role과 rolebinding간 namespace를 동일하게 맞추는 것 잊지말자.

role, rolebinding을 조회하는 명령어.

내 권한이 특정 resource에 접근 가능한지 확인하는 방법이다.

#kubectl auth can-i [ ]

resourcename에 대한 권한도 rules 아래에 줄 수 있다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

Authorization이 왜 필요할까?

클러스터는 다양한 clients들이 함께 사용하는데, 각자의 권한에 따라 기능을 제한하기 위함이다.

Authorization Mechanisms은 크게 4가지가 있는데, 하나씩 알아보자.

- Node Authorizer: named/pods system node내에서 발생하는 요청들은 Node Authrrizer에 의해 처리된다.

권한들은 kubelet에 의해 요구되기 때문에, cluster 내에서 일어난다.

external access to API

유저마다 권한이 다른데, 이걸 하나씩 직접 policy 파일에 등록/수정해야한다.

사람이 많아질수록 관리가 어려워지는데, 이를 위해 RBAC가 나왔다.

RBAC(Role Base Access Control):

유저마다 각각 policy를 만들지 않고, Developer, Security와 같은 Role을 만들어서 유저들을 해당 role에 associate한다.

이렇게 하면, role에서 수정된 내용들이 각 user에도 모두 적용되어 관리가 쉬워진다.

opensource를 쓰고 싶다면, open Policy Agent를 쓰면 된다.

open policy agent는 3rd party tool로 admission control & authorization을 도와준다.

남은 메커니즘으로 2가지가 더 있는데, AlwaysAllow와 Always Deny로 조건없이 항상 허용/거절하는 것이다.

그럼 이런 메카니즘들을 어디에 설정할까?

kube-apiserver에 설정된다. 만약 아무 값도 설정하지 않는다면, AlwaysAllow가 default 값이 된다.

그럼, 여러 개의 모드가 작성되어 있으면?

작성된 순서에 따라 체크를 하고, 각 모드에서 관련된 것이 없다면 다음 모드로 체크한다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의