[CKA] 38. k8s에서 사용자 추가 및 권한 제어

개요

k8s에서 사용자를 추가하는 방법을 알아보고 사용자의 권한을 제한하는 방법을 알아보겠습니다.

그럼 사용자를 생성하는 방법부터 시작하겠습니다. 

핵심

csr을 이용하여 CertificateSigningRequest를 적용한 후 승인 한다.

이때 csr은 base64로 인코딩된것을 사용한다.

사용자 추가 절차

1. 개인키 생성

2. csr 생성

3. CertificateSigningRequest Object 생성
    이때 csr을 base64 로 인코딩한 값을 사용합니다. 

4. CertificateSigningRequest Object 승인

    승인은 contoller-manager에서 담당합니다.

5. 승인된 CertificateSigningRequest Object에서 승인된 인증서 가져오기

6. 승인된 인증서를 가지고 apiserver와 통신

사용자 추가 상세 절차

Kubernetes에서 신규 사용자를 추가하는 것은 인증서를 생성하여 k8s에 등록하는 것입니다.

먼저 Certificate Authority (CA)를 사용해 사용자를 위한 X.509 인증서를 생성해야 합니다. 아래는 간략한 단계별 가이드입니다

개인키 생성

openssl genrsa -out test-user.key 2048

CSR 생성

openssl req -new -key test-user.key -out test-user.csr -subj "/CN=test-user"

CN의 용도

Kubernetes에서 X.509 인증서의 CN (Common Name) 필드는 인증서의 주체를 식별하는 데 사용됩니다. Kubernetes의 RBAC (Role-Based Access Control) 및 인증 메커니즘과 함께 작동할 때, CN 필드의 값은 특히 중요합니다. Kubernetes에서 CN 필드는 주로 다음과 같은 용도로 사용됩니다:

 

1. 사용자 식별

클라이언트 인증서의 `CN` 필드는 사용자 이름으로 해석됩니다. 예를 들어, `CN`이 "alice"인 사용자가 클러스터에 액세스 하려고 할 때, Kubernetes는 "alice"라는 이름의 사용자로서의 요청을 인식합니다. 

2. 노드 식별

kubelet (쿠버네티스 노드 에이전트)는 특정 노드를 대표하여 API 서버에 인증합니다. 이때 사용되는 인증서의 `CN`은 일반적으로 해당 노드의 이름으로 설정됩니다.

3. 특수 서비스 어카운트 인증서

Kubernetes v1.11 이후, API 서버로부터 토큰을 확인하기 위해 서비스 어카운트가 사용하는 인증서의 CN 값은 "system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)" 형식을 갖습니다.

4. 시스템 구성 요소

일부 시스템 구성 요소 (예: kube-controller-manager, kube-scheduler 등)는 자체 인증서를 사용하여 API 서버에 인증합니다. 이러한 구성 요소의 인증서는 일반적으로 "system" 접두어를 가진 `CN` 값을 가집니다 (예: `system:kube-controller-manager`).

5. 하위 호환성

초기의 Kubernetes 버전에서는 RBAC이 도입되기 전에 CN을 사용하여 권한을 부여하는 방식이 일반적이었습니다. 이런 이유로, 몇몇 설정에서는 오래된 클라이언트나 도구가 여전히 CN 기반의 인증 방식을 사용할 수 있습니다.

이러한 사용 사례들에 더해, X.509 인증서의 `CN` 필드는 일반적으로 인증서의 주체 (즉, 인증서의 소유자)를 명확히 식별하기 위한 목적으로도 사용됩니다.

CSR 내용 확인 

openssl req -in test-user.csr -text -noout

CSR 객체 생성 및 적용

빨간색 부분은 해당 명령어를 실행한 값을 넣으면 됩니다. 

csr.yaml

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: test-user
spec:
  request: $(cat test-user.csr | base64 | tr -d '\n')

  groups:

  - system:authenticated
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - digital signature
  - key encipherment
  - client auth

실제 파일 상태

groups에는 접근하려는 group이 들어갑니다. 

csr.yaml 적용

kubectl apply -f csr.yaml

CSR 승인 상태 확인

kubectl get csr

CSR 승인/거부 및 확인

승인

kubectl certificate approve test-user

거부

kubectl certificate deny test-user

확인

kubectl get csr

삭제 

kubectl delete csr agent-smith

승인된 인증서 가져오기 및 확인

가져오기

kubectl get csr test-user -o jsonpath='{.status.certificate}' | base64 --decode > test-user.crt

확인

openssl x509 -in test-user.crt -text -noout

통신 확인

curl  https://192.168.0.26:6443/api/v1/namespaces/default/pods --cert test-user.crt --key test-user.key --cacert /etc/kubernetes/pki/ca.crt

통신은 되나 권한이 없어서 조회가 안됩니다. 그러므로 사용자에게 권한을 추가해 보겠습니다.

추가정보 - CSR 인증 담당 service

service 이름

controller-mnager

설정 파일

/etc/kubernetes/manifests/kube-controller-manager.yaml

 

highlight 된 부분이 인증서의 signing에 사용하는 CA파일입니다.

사용자 권한 추가

RBAC이용하여 등록된 사용자게 권한을 추가합니다.

https://doitnow-man.tistory.com/entry/CKA-40-Authorization-%EA%B6%8C%ED%95%9C%EB%B6%80%EC%97%AC#rbac

정리 

k8s에서는 인증서 기반으로 사용자를 추가할 수 있습니다.

그리고 해당 인증서를 kubeconfig에 등록해서 쉽게 사용할 수 있습니다. 
[CKA] 39. kubeconfig 구조 분석 및 관리

[CKA] 38. kubeconfig 구조 분석 및 관리

Next Post

[CKA] 39. kubeconfig 구조 분석 및 관리