Authorization

 

인증이 필요한 이유는?

 

- 클러스터 관리자로써 모든 접근 제어를 others에게도 부여 할 시 심각한 문제를 발생 시킬 수 있다.

- 권한 축소가 필요하다.

(k8s 접근 제어 기본 값은 AlwaysAllow이다.)

 

Node - Auth

---

- Certification을 직접 받아서 접근 제어 가능하다.

 

ABAC (Attribute Based Access Control)

---

- Api 접근 설정을 kubeapi에 직접하여서 새로운 계정 또는 other이 접근 할 때 마다 접근 가능한 영역을 직접 셋팅해야한다.

 

 

RBAC (Role Based Access Control)

---

- 역할에 따라서 연결 할 수 있으므로 연결된 사용자 셋팅을 전부 관리할 수 있어 관리에 용이하다.

 

1. role을 만든다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing ConfigMap
  # objects is "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

2. 역할 바인딩을 한다.

 

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # The namespace of the RoleBinding determines where the permissions are granted.
  # This only grants permissions within the "development" namespace.
  namespace: development
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: configmap-updater
  apiGroup: rbac.authorization.k8s.io

역할 보는 명령어 : k describe -n <대상 네임스페이스> roles <role이름>

 

역할 바인딩 어디로 돼었는지 체크 하는 명령어: k describe rolebindings <name>

 

 

유저 역할 보기 : kubectl auth can-i <명령어 뭐 쓸지> --as <유저 이름>

Cluster Role

---

kubectl api-resources --namespaced=false # 해당 옵션을 사용하면 네임스페이스 내부가 아닌 외부에서 설정 될 수 있는 Cluster scoped 명령어를 볼 수 있다.

 

- 클러스터 단위에서의 명령어 제한은 어떻게 할까? 전과 같이 resources 단위에 지정하면 되지만 clusterrole은 네임스페이스에 좌지우지 되지 않는다.

 

 

 

 

 

Tip

---

k8s api 서버 확인

 

 

k8s clusterrole 갯수 확인하기( | wordcount 명령어로 확인 )