[겉핥기 시리즈] 넌 deploy 만 신경써, 시크릿은 내가 관리할게! - Vault 편

 

 

쿠버네티스에선 컨피그맵과 시크릿을 통해 환경변수나 파일을 전달해줄 수 있습니다.

특히 민감한 정보인 경우 시크릿을 통해 배포하게 됩니다. 하지만 시크릿은 문제가 하나 있습니다. 이름은 시크릿인데.. 인코딩만 해줄뿐 전혀 시크릿스럽지 못합니다.

 

디코딩 하면 값이 보여짐

 

따라서 시크릿을 사용하는 Helm Chart 을 생성한 후, 깃허브에 올리게 된다면 결국 그 시크릿 값은 그대로 노출됩니다. 

프라이빗 레포지토리라 해도, 민감한 정보는 깃 허브에 올리면 안된다고, 깃헙 자체에서도 가이드합니다

 

그럼 이런 시크릿을 어떻게 시크릿스럽게 사용할 수 있을까요? 다행히 이미 좋은 솔루션이 존재합니다. 

바로 HashiCorp 의 Vault 입니다. 

 

Vault 는 Secret Manager 시스템으로 이름 그대로 시크릿을 관리해주는 시스템입니다. 

 

Vault 를 이용한다면 민감한 데이터를 시크릿 리소스에 명시하지 않아도 되기 때문에 노출될 일이 없어지게 됩니다.

그럼 Vault 는 어떻게 이걸 가능하게 할까요?

 

이번 글에서는 간단한 예제를 통해 Vault 를 알아보고자 합니다.

 

그럼 렛츠두더코드~

 

 

Vault 설치

---

Vault Install Mode 는 크게 Dev Mode, Single Node Mode(Stand Alone), HA Mode 가 있는데, 이번 글에서는 Dev Mode 로 설치합니다.

 

Vault 에는 Seal, Unseal 이라는 아주 중요한 개념이 있는데 Dev Mode 로 진행하면 항상 Unseal 상태로 존재하기 때문에 이를 신경쓸 필요가 없죠. 그래서 Dev Mode 로 진행합니다.

 

설치는 Helm Chart 로 진행하고, Dev Mode 는 매우 간단합니다.

 

설치 관련 공식 문서은 여기!

 

value 몇 개를 수정하기 위해서 values.yaml 이라는 파일을 따로 만든 후 제공되는 차트의 values.yaml 을 그대로 복사해줍니다.

 

이후 .dev.enabled 는 true 로, .standalone.enabled 는 false 로 해줍니다.

 

그리고 ui 를 사용할 것이기 때문에 .ui.enabled 또한 true 로 해줍니다.

 

이제 helm install 명령어를 통해 Dev Mode 의 Vault 를 설치해줍시다.

 

성공적으로 설치가 되었네요!

 

그럼 ui 도 확인해볼까요?

8200 포트로 port-forwarding 을 통해서 접근이 가능합니다.

Token 값은 values.yaml 에 명시되어 있으며, 기본 값은 root 입니다.

 

 

좋습니다!

 

 

Agent Injector vs Vault CSI Provider

---

 

실습에 앞서 아주 중요한 Vault Component 를 잠깐 알아보고자 합니다.

바로 Agent Injector 과 Vault CSI Provider 이죠.

 

먼저 Agent Injector 입니다. 

Agent Injector 출처 : Vault Docs

핵심 개념은 바로 Admission Controller 의 Mutate 기능을 사용한다는 것이죠!

이스티오가 Admission Controller 를 통해서 파드 생성 시 프록시를 생성해주는 것과 마찬가지로 Agent Injector 는 파드가 Vault 의 시크릿을 사용할 수 있도록 파드 스펙을 변경(Mutate) 해줍니다.

 

Admission Controller 가 궁금하다면 여기를 참고해주세요!

 

그리고 PV 가 아닌 EmptyDir 을 이용해 메모리를 공유합니다. 이건 뒤에서 예제 보시면 쉽게 이해가 되실 겁니다.

 

다른 하나는 Vault CSI Provider 입니다.

Vault CSI Provider 출처 : Vault Docs

우선 눈에 띄는 건 Agent Injector 와 다르게 CSI Provider 는 데몬셋으로 띄어지게 됩니다. 따라서 모든 노드에 띄어지게 됩니다.

CSI(Container Storage Interface) 라는 이름에 걸맞게 각 노드에 있는 볼륨에 Vault 데이터를 저장하게 되고 파드가 이를 가져다 사용하는 방식이죠.

 

이건 제가 따로 노션에 정리한 글인데 보시면 아마 대략적인 차이점을 느끼실 수 있을 겁니다.

노션

 

이번 실습에서는 Vault Agent Injector 방식을 사용합니다.

 

실습

---

그럼 이제 바로 실습을 해보죠.

 

실습에 사용한 시크릿 데이터부터 만들어보죠. Vault 는 CLI, API, UI 모두 가능하지만 여기선 편하게 UI 를 사용해서 데이터를 만들어보겠습니다. 오른쪽 상단에 Enable new engine+ 를 클릭합니다.

 

KV 를 선택합니다 (KV 는 Key / Value 의 줄임말)

 

path 는 database-secret(아무거나 상관X) 로 해줍니다. Vault 에 있는 모든 데이터는 전부 Path 를 통해서 접근하게 됩니다.

 

이후 오른쪽 상단에 Create secret + 를 눌러줍니다.

 

시크릿 데이터를 입력한 후 Save 를 눌러줍니다.

 

이로써 우리는 Vault 에 시크릿 데이터를 만들었습니다. 그럼 이제 이 만든 데이터를 쿠버네티스에서 사용해야겠죠?

 

들어가기 앞서 또 한가지 짚고 넘어가야 하는 부분이 있습니다.

바로 Connectivity 입니다.

쿠버네티스에서 Vault 시크릿 데이터에 접근이 가능해야하고, 반대로 Vault 또한 쿠버네티스에 접근이 가능해야 합니다.

 

이를 위한 작업을 바로 해보죠.

 

오른쪽 상단에 Enable new method + 를 눌러줍니다.

 

쿠버네티스를 선택해줍니다. 

 

이대로 Enable Method 를 눌러줍니다.

 

그리고 k8s host 와 k8s cert 를 넣어줍니다.

 

k8s host 와 k8s cert 를 확인하는 방법입니다.

# get k8s host
kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " "

# get k8s cert
kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}' | base64 --decode

 

kubernetes auth method 가 생성되었습니다. 클릭해줍시다.

 

쿠버네티스에서 사용하게 될 Vault Role 을 오른쪽 Create Role+ 를 눌러 생성합니다.

 

아래처럼 Role 을 생성합니다.

 

쿠버네티스가 사용하게 될 Vault Role 이 생성되었습니다.

AWS IRSA 동작방식과 매우 유사합니다.

 

위에서 default 라는 Policy 를 Role 에 맵핑시켜줬는데 해당 Policy 는 아까 만든 시크릿 데이터에 접근할 수 있는 권한이 현재 없어요. 그래서 권한을 생성해줍니다.

 

default 를 누릅니다.

 

오른쪽 상단에 Edit Policy 를 누릅니다.

아래와 같이 권한을 추가합니다.

 

자, Vault 에서의 작업은 끝났고, 이제 쿠버네티스로 넘어가 봅시다.

 

서비스 어카운트의 이름과 네임스페이스는 반드시 위에서 만든 auth method 와 일치해야 합니다.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: db-auth
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: role-tokenreview-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: db-auth
    namespace: default

 

이후 deployment 를 작성하고, 배포합니다. 더 자세한 예제 설명이 보고 싶다면 여기!

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-example-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app-example
  template:
    metadata:
      labels:
        app: app-example
      annotations:
        vault.hashicorp.com/agent-inject: 'true'
        vault.hashicorp.com/agent-inject-secret-db-cred: 'database-secret/cred'
        vault.hashicorp.com/agent-inject-template-db-cred: |
          {{- with secret "database-secret/cred" -}}
          postgres://{{ .Data.data.username }}:{{ .Data.data.password }}@postgres:5432/appdb?sslmode=disable
          {{- end }}
        vault.hashicorp.com/auth-type: 'kubernetes'
        vault.hashicorp.com/auth-path: 'auth/kubernetes'
        vault.hashicorp.com/role: 'db-cred'
    spec:
      containers:
        - name: app
          image: 'nginx'
      serviceAccountName: db-auth

시크릿을 Injection 하는 방법은 위처럼 Annotation 을 사용하는 방법과 Configmap 을 사용하는 방법이 있습니다.
위와 같이 Annotation 을 사용한다면 Vault 관련 Annotation 을 Deployment 레벨이 아닌 Pod 레벨에 명시해야 합니다.

 

 

문제 없이 생성이 잘되었습니다.

 

만약 생성이 안된다면 아래와 같은 방법으로 디버깅이 가능합니다.

 

그럼 이제 생성한 파드에 들어가서 Vault 의 시크릿 데이터를 제대로 가져왔는지 확인해보죠!

/vault/secrets 은 Vault 에서 사용하는 예약 경로이며, tmpfs 로 휘발성 데이터를 저장합니다. 

사이드카 패턴으로 생성되는 Agent Injector 컨테이너와 EmptyDir 로 메모리를 공유합니다.

 

Vault 에서 시크릿 데이터를 안전하게 가져올 것을 확인할 수 있습니다. 

 

추가적으로 사이드카로 실행되는 vault-agent 도 확인해보죠!

 

같은 경로를 공유한다는 사실을 확인할 수 있습니다. 그리고 저 경로에 가면 db-cred 정보가 있죠. 위에서 본 파일과 같은 파일입니다.

 

K8S 에서 Secret 를 생성하지 않았는데 민감한 데이터를 불러올 수 있죠!!
신기하지 않나요? :)

 

API Explorer

---

추가적인 팁입니다.

Vault UI 에서 터미널을 클릭한 후 api 를 실행하면 스웨거 기반으로 만들어진 API 문서에 접근할 수 있습니다.

 

이것저것 확인해볼 수 있어서 편리합니다.

 

 

마무리

---

현재 Vault 를 공부하고 있는데, 정말 유용한 프로젝트인거 같아요. 예전부터 쿠버네티스 시크릿 관리가 문제였고, 이를 Vault 로 관리해야지~ 했는데 이제서야 진행하게 되네요.

 

AWS EKS Best Practice 를 보면 시크릿을 관리할 때 Vault 를 쓰라고 명시되어 있을 만큼 쿠버네티스 클러스터에 있어서 핵심적인 컴포넌트입니다.

 

Vault 사용은 Karpenter 때와 비슷하게 되게 신선한 경험이였고, 충분히 깊게 공부할만한 가치가 있다고 생각합니다.

 

위에서 보여드린 Vault 는 1% 도 안되는 기능으로써, 앞으로 더 열심히 Vault 를 공부해봐야 겠습니다.

 

그럼 오늘은 여기까지!