Kubernetes 클러스터 접근 구성하기 / kubeconfig, User Account, Service Account

Kuberenetes를 통해 클러스터 서버를 구성하다보면 생기는 상황이다.

  - 관리해야할 클러스터 서버가 늘어남

  - 하나하나 control-plane에 접속하며 context를 관리하다보면 복잡함

  - 어떻게 각각 클러스터에 편리하게 접근할 수 있을까?

이렇게 flow가 구성된다.

클러스터 접근을 구성하는 방식으로 kubeconfig, User Account, Service Account 등이 있는데, 각각 찾아봤다.

 

Kubeconfig

---

https://kubernetes.io/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/

kubeconfig 파일을 사용하여 클러스터 접근 구성하기

kubernetes 클러스터를 구성하고 나면 생기는 kubeconfig 파일을 통해 클러스터 접근을 하는 방식

보통 control-plane 노드에 $HOME/.kube 디렉토리에 config 파일에 kubeconfig 정보가 있음

https://kubernetes.io/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

kubectl config use-context 명령어를 통해 control-plane에서 local로 가져온 kubeconfig를 사용하여 접근 가능

context별 설정을 해두고 앞선 명령어를 통해 context를 변경하며 접근하는 방식

하지만 나는 좀 더 편하게 사용할 수 있도록 도와주는 kubectx를 사용한다.

kubectx 링크를 통해 접근하면 잘 설명되어 있긴 하지만 간단하게 적어보면

1. kubectx 설치

2. 사용하는 bash에다가 설명에 맞게 설정 추가

3. kubeconfig를 가져와 local에 저장

4. bash에 export KUBECONFIG=$KUBECONFIG:(kubeconfig 주소1):(kubeconfig 주소2...)를 추가

5. kubectx(context) + kubens(namespace) 사용

이렇게 사용하면 된다.

나는 fzf 까지 사용하여 interactive mode로 사용 중이다.

그리고 추가적으로 kubeconfig는 1년주기로 만료가 되기때문에 주기적으로 갱신해줘야하는 귀찮음이 있다.

 

클러스터를 나 혼자 접근하고 사용한다면 kubeconfig를 사용하면 되겠지만, 타 사용자들에게 클러스터 접근이 필요하다면 권한과 접근분리를 위해 사용되는 User Account, Service Account에 대해서도 찾아봤다.

 

User Account

---

Kubernetes에서 공식적으로 지원하는 기능보단 외부와 연계하여 사용하는 인증기능

말그대로 User를 지원하기 위해 생성하는 것이고, 보통 전역으로 관리

즉 특정 사용자 chicken-developer를 만들고 특정 네임스페이스에만 접근할 수 있도록 해주는 것으로 보면 됨

보통 openssl로 인증서를 만들어 해당 계정으로만 접근할 수 있도록 제한

User account 생성(openssl) -> 권한(role) 생성 -> User account와 role연결 (rolebinding) 순서로 적용

https://devopstales.github.io/kubernetes/k8s-user-accounts/

How to create Users in Kubernetes the right way?

User account와 rbac를 통해 생성하는 방식은 여기 나와있는데,

Why I need a user account insted of service account?
A service account is wisible and its token can be mounted in to a pod so threat pod has the same privileges as you.

User Account를 사용하는 케이스에 대한 이유를 찾아봤다. 오타가 좀 있는 것 같아서 수정했습니다 조금..

보안의 관점에서 Service Account는 권한이 좀 더 많기 때문에 pod에 위협이 될 수 있다는 것으로 보면 될 것 같습니다.

 

Service Account

---

User Account는 외부의 유저 접근권한에 사용됐다면, Service Account는 pod권한에 좀 더 가까움

즉, User Account는 User -> 클러스터 혹은 특정 서비스에 접근할 때 사용되는 것이고

Service Account는 Pod(service)가 접근할 때 사용되는 권한

 

Service Account 생성 -> Pod명세(deployments)에 serviceAccountName명시 -> Role생성 및 Rolebinding(어떤 api, resource등에 접근할 수 있는지에 대해 role생성후 SA에 바인딩) -> 생성된 토큰(/var/run/secrets/kubernetes.io/serviceaccount/token)으로 클러스터 접근 가능

pod접속 후 service로 curl 요청 보낼 때 헤더부분에 --header "Authorization: Bearer $TOKEN" --insecure 를 추가하여 요청

#Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: service-account-test-sa
  namespace: chicken-dev
  
#Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-account-test
  namespace: chicekn-dev
...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service-account-test
  template:
    metadata:
      labels:
        app: service-account-test
    spec:
      serviceAccountName: service-account-test-sa #service account부분
      containers:
...

#role 명세 중 rules일부
...
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - list
  - watch
  
#rolebinding중 일부
...
roleRef:
  kind: Role 
  name: service-account-test
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: service-account-test-sa
    namespace: chicken-dev
...

 

추가적으로 SA 적용 자동화에 대해서는 다양한 Controller들이 있는데, 직접 적용해보면서 자세하게 공부해볼 예정