[kubernetes] Authorization, cluster role

authorization, 말그대로 권한이나 허가이다.

서버에 여러 component가 있고, 여러 user가 존재한다. 그런데 관리자가 아닌 일반 사용자가 node를 삭제하는등 component를 마음대로 조작해버리면 문제가 발생할 수 있다.

따라서 user에 따라 kubernetes 접근에 제한적 기능은 주고싶을 때 kuberenets는 권한을 부여할 수 있는 기능을 제공한다.

4가지 Authorization이 있다.

1. Node

2. ABAC(Attribute-Based Access Control)

3. RBAC(Rule-Based Access Control)

4. webhook

간단하게 뭔지 살펴보고, 제일 자주 사용한다는 3번을 좀 더 살펴보자.

1. Node

지난번에 kubelet에 cert를 발급할 때 node를 special group으로 묶는다고 했다. 노드는 시스템의 특권을 부여하여 kubelet이 api operation (read, write)를 할 수 있는 권한이다.

2.ABAC

json format으로, user or group에 permission attribute를 설정한다.

--> 개별 유저 or group마다 권한을 설정해주어야 하므로 관리하기가 까다롭다.

--> 새로운 유저가 들어와 수정하게 되면, kube-api를 재시작해야 한다. (정보를 update 해야한다..)

example)

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}

3. RBAC

ABAC와 다르게 rule을 먼저 만들어두고, user나 group을 mapping하는 방법이다.

--> rule 수정이 필요한 경우 kube-api를 재시작하지않고 reflect만 해주면 된다.

example)

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

4. webhook

http 콜백으로, 어떤 event가 발생할 때 http post가 발생한다.(간단한 notification) 주로 써드파티 모듈을 함께 사용한다.

flags for authorization module

--authorization-mode=ABAC Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
--authorization-mode=RBAC Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
--authorization-mode=Webhook WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST endpoint.
--authorization-mode=Node Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
--authorization-mode=AlwaysDeny This flag blocks all requests. Use this flag only for testing.
--authorization-mode=AlwaysAllow This flag allows all requests. Use this flag only if you do not require authorization for your API requests.

** kube-api configuration에서 flag를 확인할 수 있다. 이 때 --authorization-mode=Node,RBAC,webhook 과 같이 multiple mode를 지원한다.

=> 명시된 순서대로 request handle

(Node request - deny 시, RBAC request - allow 시, webhook 무시)

제일 자주사용하는 RBAC를 좀 더 살펴보자

다시 RBAC를 살펴보면. rule을 먼저 만들어두고, user를 mapping하는 방법이다. 총 2개의 yaml 파일을 만들어보자.

1. role

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

위에서 보았던 role이다. rules에 array value로 접근하고자하는 resource와 허용하는 kubelet command를 사용하게 된다. 예시에서는 role은 pods의 get, watch, list 정도만 가능한 "pod-reader"라는 role이다.

** role은 항상 특정한 namespace을 명시하게 된다. (특정 namespace에 대한 rule을 설정해 주는 것)

2. rolebinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
	name: devuser-deveplopers-binding
subjects:
    - kind: User
      name: dev-user
      apiGroup: rbac.authorization.k8s.io
roleRef:
    kind: Role
    name: pod-reader
    apiGroup: rbac.authorization.k8s.io

이 pod-reader라는 role을 dev-user와 mapping, 즉 binding 해주는 rolebinding yaml 파일이다.

해당 yaml을 apply하여 default namespace에 특정 user(dev-user)에게 pod-reader role을 부여하게 된다.

** rolebinding은 같은 namespace의 role을 참조할 수 있다.

이 때 권한이 잘 부여되었는지 확인할 때에는

>> kubectl auth can-i get pods
yes

>> kubectl auth can-i create pods
no

이런식으로 kubectl의 auth can-i command를 이용해서 권한을 확인할 수 있다.

*** resource, verb 뿐만 아니라. rules의 resourcenames attribute로 특정 component에만 권한을 부여할 수 있다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  resourceNames: ["podA", "podB"]

clusterrole을 살펴보자. 언뜻 role과 비슷해보이지만, clusterrole은 namespace가 없이, cluster-wide하게 작동하는 role이다. 언제사용하냐..?

define permissions on namespaced resources and be granted within individual namespace(s)
define permissions on namespaced resources and be granted across all namespaces
define permissions on cluster-scoped resources

공식 홈페이지에서도 cluster-wide 하게 define할 떄 사용하라고 한다. 예시를 한 번 보자.

1. clusterroles

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

특정 namespace에 상관없이, cluster 단위에서 secrets resource의 get, watch list를 허가해주는 role이다.

2. clusterbinding

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

위의 role을 cluster 단위에서 binding 시켜주는 clusterrolebinding이다. 아까 rolebinding과는 달리 모든 namespace에서 manager라는 user는 secret-reader role을 수행할 수 있다.

**출처

kubernetes 공식 authorization overview: kubernetes.io/docs/reference/access-authn-authz/authorization/

1. node authorization: kubernetes.io/docs/reference/access-authn-authz/node/

2. ABAC: kubernetes.io/docs/reference/access-authn-authz/abac/

3. RBAC: kubernetes.io/docs/reference/access-authn-authz/rbac/

4. webhook: kubernetes.io/docs/reference/access-authn-authz/webhook/