RBAC 설정

▪︎ RBAC ?

---

💡 RBAC : 역할 기반 액세스 제어 (Role Based Access Control)

• 누가(주체), 무엇을(동사), 어디에(네임스페이스)를 실행할 수 있는지 결정하는 액세스 관리 형식
• 사용자 이름으로 액세스 권한을 부여하던 기존 ABAC에서 발전한 형태

 

💡 ABAC : 속성 기반 액세스 제어 (Attribute Based Access Control)

 

• K8s Service 클러스터 생성 시 클러스터를 생성한 Sub Account와 Root 계정은 클러스터 RBAC system:masters 그룹에 자동으로 설정된다.
• 클러스터 사용 권한을 IAM 유저에게 부여하려면 kube-system 네임스페이스에 ncp-auth ConfigMap을 등록해야 한다.

 

 

⭐️ 목적

---

각 Sub Account 마다 namespace를 할당하고 자신의 namespace에서만 리소스 접근 권한 부여하기 ❗️

 

 

▪ API objects

---

• Role
  • 특정 namespace 안에서 수행할 수 있는 권한
• ClusterRole
  • non-namespace 리소스이며 클러스터 전체에서 수행할 수 있는 권한
• RoleBinding
  • 특정 namespace 안에서 사용자나 사용자들 집합에게 Role안에서 정의한 권한을 부여
  • ClusterRole을 참조할 수 있으며 RoleBinding의 namespace에 결합(bind) 가능
• ClusterRoleBinding
  • 클러스터에서 모든 namespace에 ClusterRole을 결합시키기 위한 설정

 

• 현 목적에 맞게 RBAC 인증을 사용하기 위해 필요한 권한과 API object를 생각해보자 !
  • 개인의 namespace 안의 리소스만 접근 및 수정 가능
  • Group으로 관리
    • node와 namespace를 볼 수 있는 ClusterRole + ClusterRoleBinding
    • 특정 namespace 내의 리소스를 관리할 수 있는 Role + RoleBinding

 

🙌  먼저 NCP 가이드에 나와있는 configmap 작성법을 참고하여 작성하였다.

 

▪︎ ConfigMap 작성 및 생성

---

• ncp-auth-configmap.yaml
  • subAccountIdNo
    • SubAccount 콘솔에서의 확인 가능한 SubAccount ID
  • username
    • K8s 내부에서 IAM 유저에게 맵핑할 사용자의 이름
  • group
    • K8s 내부에서 IAM 사용자에게 맵핑할 그룹 목록

apiVersion: v1
kind: ConfigMap
metadata:
  name: ncp-auth
  namespace: kube-system
data:
  mapSubAccounts: |
    - subAccountIdNo: b4e398d0-******
      username: snowcat471
      groups:
        - restricted-access-group-h
    - subAccountIdNo: 3318e510-******
      username: jungmir
      groups:
        - restricted-access-group-m
    - subAccountIdNo: d7dbe520-******
      username: fails9503
      groups:
        - restricted-access-group-j

• configmap 생성 및 확인

 

🚨 트러블 이슈 때려 잡기 !

---

• error: You must be logged in to the server (Unauthorized)
• 인증이 안되었다는 에러 메시지이므로 role에 대한 오류보다는 configmap에 IAM 계정이 제대로 안 들어갔다고 판단하였음
  • namespace: kube-system
    • namespace를 kube-system에 넣어주지 않고 default에 넣어준 바보 같은 나..
  • subAccountIdNo : ****-****
    • sub account ID number을 명시해줘야 하는데 진짜 user ID를 넣어버린 바보 같은 나..

 

 

▪︎ ClusterRole 작성 및 생성

---

• ncp-auth-clusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: restricted-access-clusterrole
rules:
- apiGroups: [""]
  resources: ["nodes", "namespaces"]
  verbs: ["get", "list"]

• 클러스터 전체에 대해 수행할 cluster role 적용

 

 

▪︎ ClusterRoleBinding 작성 및 그룹 맵핑

---

• ncp-auth-clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
	name: restricted-access-clusterrole-binding
subjects:
- kind: Group
	name: restricted-access-group
	apiGroup: rbac.authorization.k8s.io
roleRef:
	kind: ClusterRole
	name: restricted-access-clusterrole
	apiGroup: rbac.authorization.k8s.io

 

• 클러스터 전체에 대한 cluster role을 restricted-access-group 그룹에 맵핑

 

 

▪︎ Role 작성 및 생성

---

• ncp-auth-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
	namespace: <specific-namespace>
	name: restricted-access-role
rules:
- apiGroups: [""]
	resources: ["pods"]
	verbs: ["get", "list"]
- apiGroups: ["apps"]
	resources: ["deployments", "daemonsets", "statefulsets", "replicasets"]
	verbs: ["get", "list"]
- apiGroups: ["batch"]
	resources: ["jobs"]
	verbs: ["get", "list"]

 

• 각 사용자의 namespace에 맞춘 role 생성
  • 한꺼번에 적용시키면 편하지만 처음이라 하나하나 해보고 싶었던..ㅎ

 

 

🚨 트러블 이슈 때려 잡기 !

---

• kubectl get pods -n mir에 대한 명령어 에러 발생
  • Error from server (Forbidden): pods is forbidden: User “jungmir” cannot list resource “pods” in API group “” at the cluster scope
• ‘클러스터 범위 내 API 그룹 [“”] 안의 pods 리스트를 IAM 유저에게 보여줄 수 없다’
  • 권한 에러
  • rule에 대한 것이 IAM 유저에게 제대로 맵핑이 안되었나?
  • rule이 제대로 정의가 안되었나?

 

• apiGroups: ["apps"]
  • 아무리 생각해도 잘못 설정한 곳이 없다고 생각했었던 바보 같은 나..
  • resources: ["deployments", … ] → 저 리소스들에 관한 rule 정할 건데..
  • verbs: ["get", "list"] → 눈 3번 비벼도 이상하게 적은 곳 없는데..
  • apiGroups: [””] → 확실하지 않은 건 이건데..?
  • 앗.. 여기서 api 관련된 것을 어디서 볼 수 있었더라? pod의 apiVersiondeployment의 apiVersion

pod의 apiVersion

deployment의 apiVersion

• 위 그림 참고.. 
  • 결국 pod에 대한 apiGroups는 [“”] 이었으며 deployment, daemonsets 등.. 에 관한 apiGroups는 [”apps”] 였다.
    
    
  • 🌈 결론 
    1. 리소스에 대한 apiVersion 잘못 작성함
    2. but, 여러 오브젝트 및 서비스에 관한 apiVersion을 확인하고 apiGroup에 넣는 법을 배웠다 !

 

 

▪︎ RoleBinding 작성 및 그룹 맵핑

---

• ncp-auth-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restricted-access-role-binding
  namespace: <specific-namespace>
subjects:
- kind: Group
  name: restricted-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: restricted-access-role
  apiGroup: rbac.authorization.k8s.io

 

• 각 사용자의 namespace에 맞춘 role에 대해 restricted-access-group에 맵핑

 

 

⭐️ 보나쓰

---

• ClusterRole/Role verbs에서 “get”과 “list”의 차이는 뭘까?
  • 둘 간의 차이 확인을 위해 RBAC의 role을 정의할 때 “list”에 대한 verbs를 제거하였다.

- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]

• kubectl get pods
  • Forbidden 에러 발생 !
• kubectl get pods <specific-pod-name>
  • 정상 출력 !
• Why?
  • 우리가 일반적으로 kubectl get pods 해서 나오는 pod 정보 리스트는 디폴트로 “list”에 대한 옵션이 들어갔다고 생각한다.
  • 그렇기 때문에 “list”에 대한 권한이 없는 경우 전체 pod에 대한 리스트를 확인 불가능하며 특정 pod에 대한 이름 정보를 옵션으로 넣어주어야 그 특정 pod에 대한 정보만 “get”으로써 확인 가능한 것이다.
  • 왜 “get”과 “list” 권한을 분리시켜놓았는지에 대한 목적을 생각해보았다.
    • 만약 특정 사용자나 개발자에게 모든 정보를 오픈하는 것보다 특정 정보만 오픈하길 원할 경우
      • 최소한의 권한 부여 → 보안 향상

 

 

ref.

---

IAM 인증 사용자 관리

Using RBAC Authorization

5 Kubernetes RBAC Mistakes You Must Avoid