RBAC

cometLEE·2023년 10월 24일

kubernetes

목록 보기

14/16

RBAC Authorization에 대해 공부한 내용을 정리한 글입니다.

쿠버네티스 공식 홈페이지 - Kubernetes RBAC를 참고하여 진행하였습니다.
또한, 마스터 노드1, 워커노드 2로 실습 진행하였습니다.
🤣🤩😊CKA 자격증 준비 및 쿠버네티스 공부 정리입니다.

서론

쿠버네티스는 보안 측면에서 다양한 기능 제공

Authentication: 클라이언트가 쿠버네티스 사용자인지 확인
Authorization: 사용자가 해당 기능의 권한을 가지는지 확인

이 중 Authorization에 대한 내용입니다.

RBAC(Role-Based Access Control)

RBAC(Role-Based Access control): 쿠버네티스가 자원에 대한 권한을 지원하는 방법중, 역할 기반으로 권한을 부여하는 방법

조직 내 개별 사용자의 역할을 기반으로 컴퓨터 또는 네트워크 리소스에 대한 액세스 규제
기존의 속성 기반 액세스제어(ABAC)에서 발전한 형태

Service Account

ServiceAccount(sa): 사용자 또는 어플리케이션에 해당
Role과 binding되어 자원접근에 사용됨.

Role

쿠버네티스에서 역할 기반 권한부여의 방법은 2가지다.

Role : Namespace에 속하는 리소스에 접근하는 권한 설정, 여러개의 Role을 생성할 수 있다.
Cluster Role: cluster 단위의 리소스들을 지정할 수 있음. Namespace에 속하지 않는 전역적인 쿠버네티스 오브젝트

NameSpace의 자원 접근

Role과 ServiceAccount를 연결해주는 역할
RoleBinding과 ClusterRoleBinding이 존재.

RoleBinding: 하나의 Role만 연결이 가능하고, ServiceAccount는 여러개 바인딩 가능

RoleBinding에 연결된 ServiceAccount들은 RoleBinding에 연결되어 있는 Role의 권한을 가지게 되어 API 서버에 접근 가능
(Role만 생성한다고 ServiceAccount에 권한이 부여되는 것이 아님!!!)

namespace 내부의 Role, RoleBinding을 구성하면 secret의 token이 생성되는데, 이 값으로 외부에서 API서버 접근. token의 권한에 따라 namespace 안에서 인가된 권한만 사용가능

Cluster 자원에 접근

clusterRoleBinding: namespace 안에 존재하는 ServiceAccount를 연결해주면, ServiceAccount가 클러스터 안에 있는 자원에 접근할 수 있게 해줌.

ClusterRole은 ClusterRoleBinding이 아닌 RoleBinding과도 연결이 가능함.
- 동일한 Role을 부여하고 관리할 때 한 번에 관리할 수 있음
- - 한 번의 변경으로 namespace에 부여된 Role 변경가능
클러스터 범위의 리소스 접근 가능
클러스터 범위 리소스 확인법

Verb(명령어)

리소스 API 엔드포인트에 대한 요청 동사를 결정하려면 사용된 HTTP 동사와 요청이 개별 리소스 또는 리소스 모음

create,get, list, watch, update, patch, delete 존재

Binding 주의점

주의점
바인딩을 생성한 후에는 바인딩이 참조하는 Role 또는 ClusterRole을 변경할 수 없습니다. 바인딩의 내용을 변경하려고 하면 roleRef유효성 검사 오류가 발생합니다. 바인딩의 내용을 변경하려면 roleRef 바인딩 개체를 제거하고 대체 개체를 만들어야 합니다.

실습 시나리오

Role과 RoleBinding을 이용해서 자신의 Namespace 내에 Pod들만 조회하는 권한 부여

my-ns라는 네임스페이스를 사용하겠습니다.

ServiceAccount 생성

$ kubectl create serviceaacount pod-viewer --namespace=my-ns

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-viewer
  namespace: my-ns

Role 생성

$ kubectl create role podreader-role --verb=get,list,watch --resource=pods --namespace=my-ns

# role 생성확인
$ kubectl get role --namespace=my-ns

$ kubectl describe role podreader-role --namespace=my-ns

#podreader-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: podreader-role
  namespace: my-ns
rules:
- apiGroups:
  - ""
  resources:	# 권한 적용할 리소스
  - pods
  verbs:	# 권한 부여
  - get
  - watch
  - list

RoleBinding 생성

$ kubectl create rolebinding podreader-rolebinding --role=podreader-role --serviceaccount=my-ns:pod-viewer --namespace=my-ns

# rolebinding 생성 확인
$ kubectl get rolebinding --namespace=my-ns

$ kubectl describe rolebinding podreader-rolebinding --namespace=my-ns

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: podreader-rolebinding
  namespace: my-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: podreader-role		
subjects:
- kind: ServiceAccount			
  name: pod-viewer				# 적용할 SA이름
  namespace: my-ns

부여된 권한 확인하기

$ kubectl auth can-i {명령어} {리소스} -n {네임스페이스} --as=system:serviceaccount:{네임스페이스}:{서비스어카운트 이름}

출력 결과가 yes면 할당된 권한, no일 경우 없는 권한

서비스 어카운트로 접근해보기

ServiceAccount별로 권한이 주어지기 때문에 다음과 같이 사용할 수 있습니다.

$ kubectl {명령어} {리소스} --as system:serviceaccount:{네임스페이스}:{계정명} --namespace={네임스페이스}

$ kubectl get pods --as system:serviceaccount:my-ns:pod-viewer --namespace=my-ns

이외에 다른 리소스로 접근하거나 verb(동작 api)를 다르게 설정하면 forbidden에러가 발생한다!

ServiceAccount에 token 생성해서 접근해보기

위에 설명한 것처럼 serviceaccount를 생성하면 토큰이 발행되어야 하는데... 없길래 찾아보았습니다.

찾아보니 1.24v부터는 보안강화를 이유로 토큰을 자동으로 발행해주지 않는다고 하더군요!! 따라서 수동으로 토큰을 발행해서 사용해보겠습니다.

# my-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: my-ns
  annotations:
    kubernetes.io/service-account.name: pod-viewer
type: kubernetes.io/service-account-token

$ kubectl get secrets --namespace=my-ns

# 토큰 확인
$ kubectl get secrets --namespace=my-ns -o yaml

시나리오 2

cluster 내 모든 namespace의 deployment, pod, service 리소스를 create, list, get, update, delete할 수 있는 권한 할당
serviceAccount 생성

serviceAccount 생성

항상 sa는 소문자로 생성!!!

$ kubectl create sa cluster-sa -n my-ns

$ kubectl get sa cluster-sa -n my-ns

clusterRole 생성

$ kubectl create clusterrole my-cluster-role --verb=create,list,get,update,delete --resource=deployment,pod,service

$ kubectl get clusterrole my-cluster-role

$ kubectl describe clusterrole my-cluster-role

cluster role은 role과 다르게 namespace설정을 따로 안해줘도 됨!!

clusterRoleBinding 생성

$ kubectl create clusterrolebinding my-cluster-rolebinding --clusterrole=my-cluster-role --serviceaccount=my-ns:cluster-sa

$ kubectl get clusterrolebinding my-cluster-rolebinding

$ kubectl describe clusterrolebindings.rbac.authorization.k8s.io my-cluster-rolebinding

서비스 어카운트로 클러스터 접근해보기

$ kubectl get pods --as system:serviceaccount:my-ns:cluster-sa --namespace=my-ns

아까와 같이 namespace안의 리소스에 대해 접근이 가능합니다.

my-ns2라는 namespace를 만들어서 deployment를 생성하고, 접근해보겠습니다.

$ kubectl create ns my-ns2

$ kubectl create deploy my-deploy --image=nginx --replicas=3 --port=80 -n my-ns2

$ kubectl get pods --as system:serviceaccount:my-ns:cluster-sa --namespace=my-ns2

이처럼 clusterRoleBinding은 namespace에 국한되는 것이 아닌, 전체 클러스터의 리소스에 대해 접근이 가능하다는 것을 알았습니다.

모든 pod들을 지워보겠습니다.

$ kubectl delete pods --all --as system:serviceaccount:my-ns:cluster-sa --namespace=my-ns2

$ kubectl delete deploy --all --as system:serviceaccount:my-ns:cluster-sa --namespace=my-ns2