[CKA] KodeKloud -Role Based Access Controls

안녕하세요, 쯀리입니다.

오늘은 Role에 따라 접근을 다르게 하는 방법인 Role Based Access Controls 줄여 RBAC이라고 많이 부르는데 이것에 대해 알아보겠습니다. 

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

Using RBAC Authorization

 

---

 

Role Based Access Control

RBAC(Role-Based Access Control)은 Kubernetes에서 사용자와 서비스 계정에 대한 권한을 관리하기 위해 사용되는 접근 제어 메커니즘입니다. RBAC는 사용자가 클러스터 내에서 수행할 수 있는 작업을 제어하고 제한하는 데 도움이 됩니다. RBAC는 주로 네 가지 주요 구성 요소로 구성됩니다: Role, ClusterRole, RoleBinding, ClusterRoleBinding.

주요 구성 요소

 

• Role: 특정 네임스페이스 내에서의 권한 정의
• ClusterRole: 클러스터 전체에서의 권한 정의
• RoleBinding: Role을 사용자, 그룹 또는 서비스 계정에 바인딩
• ClusterRoleBinding: ClusterRole을 사용자, 그룹 또는 서비스 계정에 바인딩

 

---

QUIZ.

1. Inspect the environment and identify the authorization modes configured on the cluster.
Check the kube-apiserver settings.

controlplane ~ ➜  k get pods kube-apiserver-controlplane -nkube-system
NAME                          READY   STATUS    RESTARTS   AGE
kube-apiserver-controlplane   1/1     Running   0          3m10s

controlplane ~ ➜  k describe pods kube-apiserver-controlplane -nkube-system | grep authorization
      --authorization-mode=Node,RBAC

Node,RBAC

2. How many roles exist in the default namespace?

controlplane ~ ➜  k get roles
No resources found in default namespace.

0개

3. How many roles exist in all namespaces together?

controlplane ~ ➜  k get role -A
NAMESPACE     NAME                                             CREATED AT
blue          developer                                        2024-07-19T12:15:04Z
kube-public   kubeadm:bootstrap-signer-clusterinfo             2024-07-19T12:13:44Z
kube-public   system:controller:bootstrap-signer               2024-07-19T12:13:43Z
kube-system   extension-apiserver-authentication-reader        2024-07-19T12:13:43Z
kube-system   kube-proxy                                       2024-07-19T12:13:44Z
kube-system   kubeadm:kubelet-config                           2024-07-19T12:13:43Z
kube-system   kubeadm:nodes-kubeadm-config                     2024-07-19T12:13:43Z
kube-system   system::leader-locking-kube-controller-manager   2024-07-19T12:13:43Z
kube-system   system::leader-locking-kube-scheduler            2024-07-19T12:13:43Z
kube-system   system:controller:bootstrap-signer               2024-07-19T12:13:43Z
kube-system   system:controller:cloud-provider                 2024-07-19T12:13:43Z
kube-system   system:controller:token-cleaner                  2024-07-19T12:13:43Z

controlplane ~ ➜  k get role -A | wc -l
## 제목을 제외한 수 : 12
13

제목을 제외한 수 : 12

4. What are the resources the kube-proxy role in the kube-system namespace is given access to?

controlplane ~ ✖ k describe role kube-proxy -n kube-system
Name:         kube-proxy
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources   Non-Resource URLs  Resource Names  Verbs
  ---------   -----------------  --------------  -----
  configmaps  []                 [kube-proxy]    [get]

Resources : configmaps로 설정되어있습니다. 

5. What actions can the kube-proxy role perform on configmaps?

verbs : get

 

Resources 와 Verbs는 무엇일까? ▼

Resources (리소스)

resources는 Kubernetes API에서 관리되는 리소스 유형을 나타냅니다. 여기에는 Pod, Service, ConfigMap, Secret 등 다양한 리소스가 포함됩니다. 리소스는 네임스페이스 내에서 관리될 수 있으며, 특정 Role은 해당 네임스페이스 내의 특정 리소스에 대해 작업을 수행할 수 있는 권한을 가집니다

Verbs (동사)

verbs는 리소스에 대해 수행할 수 있는 작업을 나타냅니다. 

 

6. Which of the following statements are true?

- kube-proxy role can get details of configmap object by the name kube-proxy only

 

- kube-proxy role can get details of all configmap objects in the cluster

 

- kube-proxy role can delete the configmap it created

 

- kube-proxy role can only view and update configmap object by the name kube-proxy

 

- kube-proxy role can get details of all configmap objects in the default namespace

 

 

7. Which account is the kube-proxy role assigned to?

controlplane ~ ➜  k get rolebinding kube-proxy -nkube-system
NAME         ROLE              AGE
kube-proxy   Role/kube-proxy   16m

controlplane ~ ➜  k describe rolebinding kube-proxy -nkube-system
Name:         kube-proxy
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  kube-proxy
Subjects:
  Kind   Name                                             Namespace
  ----   ----                                             ---------
  Group  system:bootstrappers:kubeadm:default-node-token

system:bootstrappers:kubeadm:default-node-token  

 

8. A user dev-user is created. User's details have been added to the kubeconfig file. Inspect the permissions granted to the user. Check if the user can list pods in the default namespace.

Use the --as dev-user option with kubectl to run commands as the dev-user.

controlplane ~/.kube ✖ k get pods --as dev-user
Error from server (Forbidden): pods is forbidden: User "dev-user" cannot list resource "pods" in API group "" in the namespace "default"

 

9. Create the necessary roles and role bindings required for the dev-user to create, list and delete pods in the default namespace.

Use the given spec:

Role: developer
Role Resources: pods
Role Actions: list
Role Actions: create
Role Actions: delete
RoleBinding: dev-user-binding
RoleBinding: Bound to dev-user

controlplane ~ ➜  kubectl create role developer --namespace=default --verb=list,create,delete --resource=pods
role.rbac.authorization.k8s.io/developer created

controlplane ~ ➜  k get roles
NAME        CREATED AT
developer   2024-07-19T12:38:00Z

controlplane ~ ➜  kubectl create rolebinding dev-user-binding --namespace=default --role=developer --user=dev-user
rolebinding.rbac.authorization.k8s.io/dev-user-binding created

controlplane ~ ➜  k get rolebinding
NAME               ROLE             AGE
dev-user-binding   Role/developer   16s

 

10. A set of new roles and role-bindings are created in the blue namespace for the dev-user. However, the dev-user is unable to get details of the dark-blue-app pod in the blue namespace. Investigate and fix the issue.

We have created the required roles and rolebindings, but something seems to be wrong.

controlplane ~ ➜  k describe roles developer -n blue
Name:         developer
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 [blue-app]      [get watch create delete]

 Resource Names이 dark-blue-app 으로 변경되어야 합니다.

controlplane ~ ➜  k edit roles developer -n blue
role.rbac.authorization.k8s.io/developer edited

controlplane ~ ➜  k describe roles developer -n blue
Name:         developer
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names   Verbs
  ---------  -----------------  --------------   -----
  pods       []                 [dark-blue-app]  [get watch create delete]

 

11. Add a new rule in the existing role developer to grant the dev-user permissions to create deployments in the blue namespace.

Remember to add api group "apps".

controlplane ~ ➜ kubectl edit role developer -n blue

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: blue
rules:
- apiGroups:
  - apps
  resourceNames:
  - dark-blue-app
  resources:
  - pods
  verbs:
  - get
  - watch
  - create
  - delete
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - create

 

 

---

오늘은 Role과 RoleBinding에 대해 알아보았습니다. 

Role로 사용자들의 접근을 풀고 허용하고 할 수 있는데요, 현업에서 정말 많이 쓰이는 방법입니다. 

 

 

---

참조

※ Udemy Labs - Certified Kubernetes Administrator with Practice Tests