• 쿠버네티스에선 보안을 위해 사용자 또는 어플리케이션에 Service Account라는 오브젝트를 할당하여, Role Based Access Control (RBAC) 을 기반으로 특정 명령을 실행할 수 있게 관리를 한다
• 예시를 들어보면
  • 사용자 A - Service Account A - Deployment 생성, 이렇게 매칭될 경우 사용자 A는 Service Account A로 쿠버네티스에 접근하여 Deployment 생성 기능을 사용할 수 있다, 허나 그 외 기능은 사용하지 못한다
  • Deployment B - Service Account B - ConfigMap 읽기, 이렇게 매칭될 경우 Deployment B는 Service Account B를 사용하여 ConfigMap을 읽을 수 있다, 허나 그 외 기능은 사용하지 못함

Service Account, Role, Cluster Role

• Service Account는 권한을 관리하기 위한 오브젝트, 보통 한 명의 사용자나 어플리케이션에 해당한다고 보면 된다
• 보통은 default라는 Service Account가 있으며, 쿠버네티스의 API를 모두 실행할 수 있는 모든 권한을 가지고 있다

• 따로 Account를 생성하지도 않았고, 권한 부여도 하지 않았지만, 바로 명령어를 수행할 수 있는 이유는 설치 도구에서 자동으로 부여해주기 때문, 이는 .kube/config 파일로 확인할 수 있다

• 보통 설치하게 되면 공개키, 비밀키를 별도로 저장하여 인증 과정을 거치게 되는데, 실제 서비스 활용시엔 절차가 복잡하기 때문에 Service Account, RBAC을 사용한다고 한다
• Service Account를 생성했으면, Account에 권한을 부여해야 하는데 쿠버네티스에선 Role 또는 Cluster Role을 사용한다
• Role은 Namespace에 속해있으며, Namespace에 속하는 오브젝트, Pod, Service, Deployment 같은 오브젝트를 제어할 권한을 부여할 수 있으며
• Cluster Role은 클러스터 수준의 오브젝트에 대한 접근 권한을 부여할 수 있다
• Role은 아래와 같은 YAML로 작성할 수 있으며

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
	namespace: default
	name: service-reader
rules:
- apiGroups: [""]
	resources: ["services"]
	verbs: ["get", "list"]

• rules 항목은 아래와 같다
  • apiGroups : 대상이 될 오브젝트의 API 그룹, 이는 kubectl api-resources로 확인 가능
  • resources : 대상이 될 오브젝트의 이름, 어떤 오브젝트의 권한을 부여할 것인지 입력
  • verbs : 어떠한 동작인지 명시, 위 예시에선 service의 get과 list 명령어를 사용할 수 있게 된다
• Role을 배포했으며, 이제 Service Account에 실제로 부여하기 위해 Binding 과정을 거쳐야 하는데, 이는 RoleBinding을 따로 생성하여 실행하면 된다

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
	namespace: default
	name: service-reader-rolebinding
subjects:
- kind: ServiceAccount
	name: testAccount
	namespace: default
roleRef:
	kind: Role
	name: service-reader
	apiGroup: rbac.authorization.k8s.io

• Cluster Role도 Role 생성 및 바인딩 과정이 동일한데, kind에 ClusterRole이란 점이 다르며, ClusterRole은 metadata의 label을 통해 여러 Cluster Role들을 연결하여 재사용할 수 있다고 한다

User, Group