(Kubernetes) Authentication, Role, ClusterRole --정리필요

 

 

쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다. 모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다. 계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다. 이는 기본적으로 승인이 거부된다는 것을 의미한다.

(쿠버네티스는 API 서버를 사용하지만, 특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은 어드미션 컨트롤러에 의해 처리된다.)

여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다. 어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다. 모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다. 요청 거부는 HTTP 상태 코드 403을 반환한다.

 

인가 모드 : kubectl describe pod -n kube-system kube-apiserver-controlplane 으로 API서버의 디스크립션에 정의되어 있다.
쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.

 

- Node : 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 Node 인가을 참조한다.

- ABAC : 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 ABAC 모드를 참조한다.

- RBAC : 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 RBAC 모드를 참조한다.
지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 rbac.authorization.k8s.io API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.

 

-Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group 
  resources: ["pods"] // 접근가능 POD
  verbs: ["get", "watch", "list"] // 수행가능한 VERB

위와 같이 Role 오브젝트를 생성하고 kubeconfig로 User를 생성한다음 두 오브젝트를 연결해주어야 한다. RoleBinding으로 묶어준다.

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

 

※Allow reading/writing Deployments (at the HTTP level: objects with "deployments" in the resource part of their URL) in both the "extensions" and "apps" API groups:

rules:
- apiGroups: ["extensions", "apps"]
  #
  # at the HTTP level, the name of the resource for accessing Deployment
  # objects is "deployments"
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

RBAC을 활성화하려면 --authorization-mode=RBAC로 API 서버를 시작한다.
Webhook - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 Webhook 모드를 참조한다.

 

※ KUBERNETES 인증서 체계의 특징 하나는 ETCD는 기타 KUBERNETES의 구성요소와는 다른 독립적인 CA를 사용한다는 것이다.

 

쿠버네티스에서 kubectl과 같은 커맨드를 사용해 API를 요청하는 과정은 크게 3가지로 구성되어 있다. 첫 번째는 '쿠버네티스 사용자가 맞느냐' 를 판단하는 인증 (Authorization), 두 번째는 'API를 호출할 수 있는 권한이 있느냐' 를 판단하는 인가 (Authorization), 마지막으로 그 요청이 적절한지를 판단하는 어드미션 컨트롤러 (Admission Controller) 이다. 

 

-ClusterRole

Namespace가 왼쪽 Scope라면 node 및 그이상의 scope는 Cluster로 정의 된다.

이에 대한 Authentication은 ClusterRole을 정위하고 ClusterRoleBinding으로 실현된다.

 

쿠버네티스의 인증

 

인가와 어드미션 컨트롤러는 쿠버네티스에 내장되어 있는 기능이기 때문에 사용 방법이 비교적 정해져 있는 반면, 첫 번째 단계인 인증은 이렇다 할 정답이 딱히 정해져 있지 않다. 물론 쿠버네티스의 자체 인증 기능인 ServiceAccount, 인증서 등을 사용할 수는 있지만, 사내에서 LADP, Google, Github 와 같은 별도의 인증 시스템을 이미 구축해 놓았다면 [기존 인증 시스템 / 쿠버네티스 인증 시스템] 을 분리해 운영해야 하는 상황도 발생할 수 있다. 그렇게 되면 인증을 위한 관리 포인트 또한 두 곳이 되어 버리기 때문에, 클러스터 매니저의 입장에서 이러한 구조는 그다지 달갑지는 않을 것이다.

 

쿠버네티스는 이러한 불편함을 해결하기 위해 OAuth (Open ID Connect) 로 서드 파티에 인증을 위임하는 기능을 제공한다. 즉, 사내에서 별도의 인증 시스템 (LDAP, Google, Github) 을 이미 운영하고 있다면 해당 인증 시스템을 그대로 쿠버네티스로 가져올 수 있다. 따라서 Github 계정을 통해 쿠버네티스의 API (ex. kubectl) 를 사용할 수 있을 뿐만 아니라, Role 이나 ClusterRole 을 Github 계정에게 부여하는 것 또한 가능해진다. 

 

 

User와 Group의 개념

 

쿠버네티스에서 가장 쉽게 사용할 수 있는 인증 기능은 바로 ServiceAccount 이다.1 그렇지만 ServiceAccount 라는 이름에서도 알 수 있듯이, ServiceAccount는 사람이 아닌 서비스 (Service), 즉 포드가 API를 호출하기 위한 권한을 부여하기 위해서 사용하는 것이 일반적이다. 물론 ServiceAccount를 사람에게 할당하는 것이 이론상으로 불가능한 것은 아니지만, Service Account의 설계 디자인을 조금만 생각해 보면 애초에 쿠버네티스 애플리케이션에 권한을 부여하기 위한 용도라는 것을 알 수 있다.2

 

그렇다면 실제 '사람' 이라는 Entity에 대응하는 추상화된 쿠버네티스 오브젝트는 무엇일지 궁금할텐데, 결론부터 말하자면 쿠버네티스에서는 사람에 대응하는 오브젝트가 없다. 쿠버네티스에는 오픈스택의 keystone과 같은 컴포넌트가 따로 존재하는 것도 아니기 때문에, 실제 '사람' 을 쿠버네티스에서 리소스로 관리하지 않는다. 그 대신, 쿠버네티스에서는 User와 Group 이라는 이름으로 사용자를 사용할 수 있다.

 

'User는 쿠버네티스 오브젝트가 아니기 때문에 따로 관리되지는 않으며, 외부 인증 방법에 따라서 달라진다' 정도가 된다. 예를 들어 Github을 쿠버네티스 인증 시스템으로 사용한다면 Github 사용자 이름이 User가 되고, Organization 이름이 Group이 된다고 이해하면 쉽다.

 

 

쿠버네티스 클러스터 root CA를 통한 사용자 인증

쿠버네티스는 기본적으로 root CA 인증서를 스스로 발급해 사용한다. 이 인증서를 이용하면 별도의 서드 파티 연동 없이도 User와 Group을 사용할 수 있다.

 

 

 

 

Certificate Signing Requests 오브젝트 만들기
yaml 파일로 만든다.

yaml의 spec.request에 csr파일의 해시를 base64로 인코딩하여 추가한다. 

base64인코딩은 툴을 이용해서 한다.

예시) echo 'hello world' | base64