쿠버네티스 인가(Authorization) - RBAC, Role, RoleBinding

yunyoung·2021년 1월 22일

쿠버네티스

목록 보기

9/12

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

Namespace 내의 권한

Role과 RoleBinding을 여러 개 만들어서 관리하면 된다.
- Role
  Role은 여러 개 만들 수 있고, Namespace에 있는 자원에 대해 read, write 권한을 줄 수 있다.
- RoleBinding
  Role과 ServiceAccount를 연결해주는 역할이다.
  RoleBinding은 하나의 Role만 연결할 수 있고, ServiceAccount는 여러 개 지정할 수 있다.
  이렇게 되면 RoleBinding에 연결된 ServiceAccount들은 RoleBinding에 연결된 Role의 역할을 가지게 되어 API 서버 자원에 접근할 수 있다.
ServiceAccount에서 Cluster 자원에 접근하는 권한
- ClusterRole
  Role과 차이점은 클러스터 단위의 오브젝트들을 지정할 수 있다는 것이다.
  ClusterRole과 Namespace 안에 있는 RoleBinding을 연결할 수도 있는데, 이 경우는 일반 Role과 RoleBinding을 사용하는 것과 동일하게 동작한다. 이렇게 구현하는 이유는 Namespace마다 똑같은 Role을 부여하고 관리해야 할 때 한 번에 쉽게 관리하기 위해 사용한다.
- ClusterRoleBinding
  ClusterRoleBinding에 Namespace 안에 있는 ServiceAccount를 연결해주면, Namespace 안에 있는 ServiceAccount가 클러스터 안에 있는 자원에 접근할 수 있게 된다.

Namespace 내의 권한

한 Namespace에 Pod와 Service가 있다고 가정한다. 이 Namespace를 만들었을 때 자동으로 생성되는 ServiceAccount와 Secret도 있다.

Role
```
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
```
pod는 코어 API이기 때문에 apiGroups를 따로 지정하지 않는다. 만약 리소스가 job이라면 apiGroups에 "batch"를 지정해준다. verbs라는 속성으로 조회만 가능하도록 속성을 주었다.

RoleBinding
```
roleRef: 
  kind: Role
  name: Role1
subjects: 
- kind: ServiceAccount
  name: SA
```
roleRef에 Role을 넣어주고, subjects에 ServiceAccount를 넣어주면 연결이 된다.

이렇게 해주면, Secret에 있는 토큰 값으로 이 API 서버에 접근할 수 있고 이 토큰에 대한 권한에 따라 이 Namespace 안에 있는 Pod만 조회할 수 있게 된다.

Namespace 안의 ServiceAccount가 모든 클러스터 안의 자원에 접근

ClusterRole
```
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
```
ClusterRoleBinding
```
roleRef: 
  kind: ClusterRole
  name: ClusterRole1
subjects: 
- kind: ServiceAccount
  name: SA
```
이렇게 되면 Namespace 안에 있는 ServiceAccount(SA)에 클러스터 안의 모든 자원에 대한 모든 권한을 준 것이 된다. Secret의 토큰 값으로 접근하면, 다른 Namespace는 물론이고 클러스터 내의 모든 자원을 조회하거나 생성할 수 있다.

🌈TIL과 개발 노트