160-164. Authorisation, RBAC and Cluster Roles

Authentication and Authorization

• Authentication은 특정 사용자가 어떤 클러스터에 접근할 수 있는지 없는지를 결정
• Authorisation은 특정 사용자가 그 클러스터에서 뭘 할 수 있는지를 결정

특정 사용자에 대해 모든 관리 권한을 다 주고 싶지 않을 수 있다

• 노드를 삭제한다든지, 네트워크를 박살낸다든지 하는 위험한 짓은 하지 말고, Pod deployment 정도는 하게 할 수 있다.
• 특정 봇에 대해서는 모니터링에 필요한 최소 권한만 주고자 할 수 있다.
• 여러 클러스터를 공유하면서 네임스페이스로 논리적 분리한 환경에서는, 관리자가 할당된 네임스페이스에 대해서만 관리 가능하게 권한을 짜고자 할 수 있다.

Authorisation의 메커니즘

Node based

예를 들어, kubelet의 인증서는 /O=system:node 그룹이어야 하고 이름은 /CN=system:node:뭐시기 형식을 따라야 한다.

• 이런 형식의 인증서를 가지고 있으면 Node-authorizer를 통해 시스템 노드 권한을 부여받는다.

Attributed-Based Access Control (ABAC)

Attributed-Based Access Control (ABAC)는 특정 사용자나 그룹에 권한-뭉탱이를 할당하는것으로, API의 외부 접근 시 등에 사용할 수 있다.

예를 들어 dev-user라는 사용자에 Pod에 대한 권한 (생성, 삭제, 확인)을 주고 싶다면,

{"kin": "Policy", "spec": {"user": "dev-user", "namespace": "*", "resource": "pods", "apiGroup": "*"}}

같은 파일을 kube-apiserver에 넣고 재시작해야한다.

이것은 별로 scale-up되기 좋은 방식은 아니다.

Role-Based Access Control (RBAC)

특정한 Role(예를 들어 developer)을 만들고 권한-뭉탱이를 할당한 뒤, 그 role을 사용할 사용자나 그룹에 전부 그 role을 associate하는것이다.

Webhook

모든 authorization을 외부 authorization provider에 맡기기

AlwaysAllow & AlwaysDeny

제곧내

Authorisation Mode를 어떻게 설정하는가?

kube-apiserver 실행 파라미터에 들어가있다. 예를 들어 kube-apiserver가 systemd service로 디플로이되어 있다면,

ExecStart=/usr/local/bin/kube-apiserver \\
...
  --authorization-mode=Node,RBAC,Webhook
...

같은 식이다.

여러 개의 authorisation mode가 설정된 경우, 서순대로 작동한다.

• 위의 예시에서는, 특정 요청이 Node에서 deny되면 RBAC로 넘어가고, RBAC에서도 deny당하면 Webhook으로 넘어간다.
  • 3개 중의 하나라도 OK사인을 주면 요청은 Accept된다.

RBAC

생성하기

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""] # Core API Group일 경우 공백으로 비워둠
  resources: ["pods"]
  verbs: ["list", "get", "create", "update", "delete"]
  # Optional: 예를 들어 특정 Pod에 대해서만 권한을 허가하고 싶은 경우:
  resourceNames: ["blue", "orange"]

이후 kubectl create -f로 생성, kubectl get roles와 kubectl describe role developer로 확인 가능하다.

사용자와 그룹을 Role에 Binding하기

이 때에는 Role Binding Object YAML 파일을 만들어야 한다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # 생성한 Role의 이름
  name: developer
  apiGroup: rbac.authorization.k8s.io

이후 kubectl create -f로 생성, kubectl get rolebindings와 kubectl describe rolebinding developer-binding으로 확인 가능하다.

사용자 입장에서 권한 확인하기

kubectl auth can-i 명령어를 이용하면 yes, no로 대답해준다

• kubectl auth can-i create deployments
• kubectl auth can-i delete nodes

관리자인 경우, 특정 사용자의 권한을 체크하는 것도 가능하다
kubectl auth --as dev-user 같은 식으로 사용하면 된다.

Cluster Roles

Role와 Role Binding은 네임스페이스된다 - 별도의 지정이 없으면 네임스페이스 default에 대한 Role과 Role Binding으로 적용된다.

하지만 생각해보자. "노드"는 네임스페이스에 할당할 수 없다!

• 이것을 Cluster-Scoped라고 함

노드처럼 Cluster-Scoped된 리소스들에는 PV, CSR, namespaces 등이 있다

• 전체를 보려면 kubectl api-resources --namespaced=true 로 확인 가능

이런 Cluster-Scoped 리소스를 할당하기 위해 Cluster Roles, Cluster Role Bindings이 존재한다

Cluster Role 생성하기

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-role
rules:
- apiGroups: [""] # Core API Group일 경우 공백으로 비워둠
  resources: ["nodes"]
  verbs: ["list", "get", "create", "update", "delete"]

Cluster Role Binding 생성하기

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects:
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # 생성한 Role의 이름
  name: cluster-admin-role
  apiGroup: rbac.authorization.k8s.io

똣갓내;;

참조사항

Cluster Role은 Cluster-Scopped 리소스뿐만이 아니라 namespaced 리소스에 대해서도 적용이 가능하다

• 만약 Pod에 대한 Cluster Role을 주었다면, 해당 클러스터에 있는 노드 전체에 대해 적용되는 것이다