[Kubernetes] RBAC, Role, RoleBinding(Authorization)

쿠버네티스 접근제어 체계

• Authentication : 접속한 사람의 신분을 시스템이 인증하는 단계 -> 신분증 확인
• Authorization : 어떤 권한을 가지고 어떤 행동을 할 수 있는지 확인하는 단계 -> 사용자별 권한 확인
• Admission Control : 인증과 권한확인 이후에 추가적인 요청내용에 대한 검증 또는 요청 내용 강제 변경

이러한 접근체계중 Authorization을 주제로 포스팅

 

 

RBAC(Role-Based Access Control)

쿠버네티스가 자원에 대한 권한을 지원하는 방법에는 여러가지 방법 중 대표적인 방법

역할 기반으로 권한을 부여하는 방법으로 Role, RoleBinding 오브젝트를 사용

• 누가(주체), 무엇을(동사), 어디에(네임스페이스) 실행할 수 있는지 결정하는 권한 또는 템플릿 집합을 수반하는 Identity 및 액세스 관리 형식
• 기존의 속성 기반 액세스 제어(ABAC)에서 발전한 형태

 

Role과 RoleBinding

Namespace에 있는 ServiceAccount의 Role와 RoleBinding을 어떻게 설정하느냐에 따라 Namespace내에 있는 자원만 접근할 수도 있고, 클러스터에 있는 자원까지 접근할 수 있다.

1. Namespace 내의 권한

• Role
• Role는 여러개 만들 수 있고, Namespace에 있는 자원에 대해 Read, Write 권한을 줄 수 있다.
• RoleBinding
• Role과 ServiceAccount를 연결해 주는 역할
• RoleBinding은 하나의 Role만 연결할 수 있고, ServiceAccount는 여러개 지정 가능
• RoleBinding에 연결된 ServiceAccount들은 RoleBinding에 연결된 Role의 역할을 가지게 되어 API 서버에 접근 가능

namespace 내부의 Role, RoleBinding 구성하였을 때, Secret의 Token값으로 외부에서 API 서버에 접근 가능

또한, Token의 권한에 따라 Namespace에서 인간된 권한만 행사 가능

 

2. ServiceAccount에서 Cluster 자원에 접근하는 권한

• ClusterRole
• 클러스터 단위의 오브젝트들을 지정할 수 있음
• ClusterRoleBinding이 아닌 Namespace 내부의 RoleBinding과도 연결가능
• 일반 Role와 RoleBinding을 사용하는 것과 동일하게 동작 -> 클러스터 자원에 접근 불가
• 동일한 Role을 부여하고 관리할 때 한번에 쉽게 관리됨
• 한번의 변경으로 모든 Namespace에 부여된 Role이 변경됨 -> 관리가 용이
• ClusterRoleBinding
• Namespace안에 있는 ServiceAccount를 연결해주면, ServiceAccount가 클러스터 안에 있는 자원에 접근 할 수 있게 된다.

Cluster Role/RoleBinding 구성하였을 때, Secret의 Token값으로 외부에서 API 서버에 접근 가능

또한, 해당 네임스페이스와 다른 네임스페이스의 자원, 클러스터 단위의 자원에서도 조회나 생성 가능

 

---

실습

1. Role, RoleBinding을 이용하여 자신의 Namespace 내에 Pod들만 조회하는 권한 부여

 

네임 스페이스 생성

kubectl create ns nm-01

 

생성한 네임스페이스에 Role생성

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: r-01
  namespace: nm-01
rules:
- apiGroups: [""]
  verbs: ["get", "list"]
  resources: ["pods"]

 

네임스페이스 내부에 Role과 연결할 RoleBinding 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rb-01
  namespace: nm-01
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: r-01
subjects:
- kind: ServiceAccount
  name: default
  namespace: nm-01

 

생성한 Role, RoleBinding 확인

 

nm-01 네임스페이스의 Secret의 Token값 확인

Postman의 Authorization - Bearer To로 해당 Token 입력,  https 요청

    -> Pod List에 대한 조회 결과를 응답 (nm-01내부 Pod가 없기 때문에 조회되는 Pod는 없음)

 

Service 생성

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    app: pod
  ports:
  - port: 8080
    targetPort: 8080

 

해당 권한으로 Service 조회 (https 요청)

    -> Pod에 대한 조회 권한만 부여했기 때문에 Service 조회는 실패 응답을 받음

---

2. Cluster Role/RoleBinding을 이용하여 모든 Namespace 내에 Object들에 대해 모든 권한 부여

Namespace 생성

apiVersion: v1
kind: Namespace
metadata:
  name: nm-02

 

이후, 해당 네임 스페이스에서 작업

 

ServiceAccount 생성

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-02
  namespace: nm-02

 

ClusterRole 생성

Role과는 다르게 namespace를 지정하지 않음

모든 자원에 대해 모든 권한 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cr-02
rules:
- apiGroups: ["*"]
  verbs: ["*"]
  resources: ["*"]

 

ClusterRole과 ServiceAccount를 연결하는 ClusterRoleBinding을 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: rb-02
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cr-02
subjects:
- kind: ServiceAccount
  name: sa-02
  namespace: nm-02

Secret Token 확인

Postman의 Authorization - Bearer To에 해당 Token 입력, https 요청

 

nm-01의 Pod 조회

nm-02의 Pod 조회

 

nm-01의 service조회

 

 

nm-02의 service조회

 

클러스터 단위인 Node 조회

    -> 모든 네임스페이스 뿐만 아니라 클러스터 단위의 자원이 조회되는 것이 확인