🌊 쿠버네티스 인증 [Static Token, Service Account, kube config, TLS, Role, RoleBinding]

모든 통신은 TLS를 통해 Kube-apiserver를 이용하여 요청함
https://kubernetes.io/docs/reference/access-authn-authz/authentication/

쿠버네티스 인증 체계

https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules

• RBAC/ABAC/Node Authorization, WebHook Mode
  • RBAC : role based access controll
  • ABAC : attribute based access controll
  • Webhook : HTTP 콜백, 특정 이벤트를 발생할때 URL에 메시지 전달

Account

• 종류: user, Service Account(애플리케이션에 사용)

---

Static Token File

Apiserver 서비스 실행 시 --token-auth-file=<토큰파일.csv>

• static pod 재설정 및 api서버를 다시 시작해야함

패스워드, 유저, 유저아이디, 그룹  #형태의 열을 작성함

--token-auth-file=<토큰파일.csv> 설정을 kube-apiserver 파드에 적용할때 컨테이너 이기 때문에 불륨마운트를 통해서 csv파일 경로를 설정해주도록 할것

kubectl에 등록된 static token 유저 등록

$ kubectl config set-credentials user1 --token=password1 : 유저에 대한 비밀번호
$ kubectl config set-context user1-context --cluster=kubernetes \ --namespace=frontend --user=user1

• 클러스터 서버를 선택하기 위한 인가 설정(kubernetes:마스터노드?)
• context -> 로그인을 통해 연결할 아이디와 kubernetes를 연결

$ kubectl get pod --user user1 : user1으로 로그인

kubernetes-admin으로 돌아오기

kubectl config use-context kubernetes-admin@kubernetes

---

서비스 어카운트

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

서비스 어카운트 확인

kubectl get sa default -o yaml (default에는 자동 생성되어있음)

• 

서비스 어카운트 생성

kubectl create serviceaccount <서비스어카운트명>

sa와 함께 시크릿도 생성됨 (시크릿 안에는 토큰값 생성)

pod에 서비스어카운트 설정

spec.serviceAccount: <서비스어카운트명>

• 설정하지 않으면 default sa로 설정됨
• sa 연결 시 토큰이 불륨 마운트됨
  https://kubernetes.io/ko/docs/tasks/administer-cluster/access-cluster-api/#kubectl-%ED%94%84%EB%A1%9D%EC%8B%9C-%EC%97%86%EC%9D%B4-%EC%A0%91%EA%B7%BC
  • 파드 내 /var/run/secrets/kubernetes.io/serviceaccount
    ca.crt, namespace, token
  • TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
  • curl -X GET https://$KUBERNETES_SERVICE_HOST/api --header "Authorization: Bearer $TOKEN" –insecure : 토큰 값을 변수로 curl 명령 실행 (insecure 인증서 기간 무시)
  • KUBERNETES_SERVICE_HOST -> pod내에 printenv를 통해서 확인
    

---

TLS

SSL 인증

Kubernetes 인증서 위치

sudo ls /etc/kubernetes/pki
sudo ls /etc/kubernetes/pki/etcd

TLS 인증서 확인

sudo ls /etc/kubernetes/manifests/

kubelet 인증서

sudo ls /var/lib/kubelet/pki
sudo ls /var/lib/kubelet/
sudo cat /var/lib/kubelet/config.yaml

인증서 정보 확인

sudo openssl x509 -in <certificate경로> -text

Issure 에 대한 정보를 확인해야함 (인증서 발급 제공자)

인증서 유효기간 확인 및 갱신

kubeadm alpha certs check-expiration : 모든 인증서 유효 확인

• kubeadm은 컨트롤 플레인을 업그레이드 하면 모든 인증서 자동 갱신
  kubeadm alpha certs renew all : 모든 인증서 새로 갱신

---

유저 from TLS 인증서

https://kubernetes.io/ko/docs/tasks/administer-cluster/certificates/

1. 개인키 발급

openssl genrsa -out <키파일명.key> 2048 : 길이 2048 개인키 생성

• 

2. 개인키를 이용해 인증서 서명 발급요청

openssl req -new -key <개인키파일.key> -out <csr파일.csr> -subj "/CN=<사용자이름>/O=<그룹이름>"

• CN : 사용자이름
• O: 그룹 이름
• ca에 인증 결과를 csr파일로 받음

3. csr승인

• 내부 직접 승인 이용시 pki 디렉터리 내에 ca.key, ca.crt 사용
• .csr 파일을 이용하여 .crt 생성
• -days 옵션 사용해 인증서 유효기간 지정

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out server.crt -days 10000 \
    -extensions v3_ext -extfile csr.conf -sha256

openssl x509 -req -in <csr파일.csr> -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out <결과crt파일.crt> -days 500

4. kubectl에 인증서 등록

4-1) 유저 설정

$ kubectl config set-credentials <유저명> --client-certificate=.certs/<ca인증서. crt> --client-key=.certs/<개인키.key>

4-2) 유저 컨텍스트 설정

$ kubectl config set-context <유저명>-context --cluster=kubernetes --namespace=office --user=<유저명>

4-3) 컨텍스트 변경

kubectl config use-context <유저인증 컨텍스트>
kubectl config use-context kubernetes-admin@kubernetes : 쿠버네티스 어드민으로 돌아오기

4-4) 명령 수행

권한이 없어서 응답이 Forbidden 으로 오는 모습

---

kube config

kube config 파일이 없으면 curl 을 통해서 명령 수행 해야함 -> 비효율적

kubeconfig 위치

cd $HOME/.kube/

kube config조회

kube config view
kube config view --kube config=<config파일명>

등록한 credential 로그인 , 컨텍스트 정보 등이 들어있음

• cluster: 연결할 쿠버네티스 클러스터 정보
• users: 사용할 권한 사용자
• contexts: cluster와 user를 이어주는 context 정보

클러스터 요청 user 및 context 변경

kubectl config use-context <컨텍스트명>@<클러스터명>

kubectl 명령어 context 지정

kubectl get pod --context <등록된 컨텍스트명>
kubectl get pod --user <등록된 유저명>
kubectl get pod --as <등록된 유저명>

---

RBAC

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

유저 권한 관리

• rbac.authorization.k8s.ioAPI를 사용
• 권한 결정을 내리고 Kubernetes Api를 통해 정책을 동적으로 구성
• RBAC를 사용하여 룰 정의시 apiserver에 --authorization-mode=RBAC 옵션 필요
  • kubeadm 설치시 이미 설정되어있음
    kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
• 롤 정의 -> 롤 부여(바인딩)

rbac.authorization.k8s.ioAPI

• 네임 스페이스 내부 (like 개발자)
  • Role
  • RoleBinding
• 네임스페이스에 구속안됨 (클러스터 전체, 관리자))
  • ClusterRole
  • ClusterRoleBinding

대시보드에 클러스터 롤을 부여하여 사용 함 : 링크

• 

리소스 - 롤(클러스터) - 롤바인딩(클러스터) - 사용자

롤

• 누가 하는 것인지는 정하지 않음
• 롤을 정의
• 일반롤(네임스페이스단위), 클러스터롤 (전체 클러스터 자원 관리)
• 권한 종류: https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb
• api 명세(필요 권한 확인): https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#pod-v1-core

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

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

롤 바인딩

• 누가 하는 것인지 정함
• 롤 정의 X
• 어떤 사용자에게 어떤 권한 부여할지 정하는 리소스
• 일반롤-일반롤 바인딩, 클러스터롤-클러스터롤 바인딩

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  # ServiceAccount로도 설정 가능
  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

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

권한 부여하기

TLS 에서 사용했던 test 유저 컨텍스트에 권한 부여

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

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User  
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role 
  name: pod-reader 
  apiGroup: rbac.authorization.k8s.io

• rolebinding에 네임스페이스를 default로 지정해주었기 때문에 해당 네임스페이스에서 사용 가능
• .csr파일만들때 O옵션이 네임스페이스인가?? 도 확인해봐야 할듯하다