VSO CSI 드라이버 설정
VSO CSI 드라이버 설정 (CSI driver setup)
CSISecrets 리소스로 Vault Secrets Operator CSI 드라이버를 구성해 승인된 파드가 Vault 시크릿을 임시 볼륨으로 마운트하게 하는 전체 절차를 다룹니다.
출처: 문서
본문
Enterprise에요. 적절한 Vault Enterprise 라이선스가 필요합니다.
CSISecrets 리소스와 함께 Vault Secrets Operator CSI 드라이버를 사용하면, 승인된 파드가 Vault의 시크릿을 담은 임시 볼륨을 인덱싱된 파일로 마운트할 수 있어요. 인덱싱은 0부터 시작하며 CSISecrets 리소스의 관련 vaultStaticSecrets 또는 vaultAppRoleSecretIDs 목록에서의 위치를 나타냅니다. 예를 들어 static_secret_0_secret, static_secret_1_secret, ... static_secret_N_secret처럼요.
CSI 드라이버는 컨테이너 시작 시 새 AppRole 시크릿 ID를 생성하고 동기화해요. 다른 모든 시크릿은 요청한 컨테이너가 시작·재시작될 때, 또는 사용자가 CSISecrets 리소스를 수정할 때 동기화됩니다.
시작하기 전에
- Vault Secrets Operator 위협 모델을 검토하세요. 아래의 단순화된 쿠버네티스 RBAC 구성 예제는 프로덕션 사용에 적합하지 않아요.
- 인증 선택이 클러스터 보안에 어떤 영향을 줄 수 있는지 이해하려면 적용 가능한 규정·요구사항을 검토하세요.
- 사용 가능한 Kubernetes 통합을 검토해 Vault Secrets Operator CSI 드라이버 기능이 요구사항을 충족하는지 확인하세요.
- 시크릿 업데이트를 위해 애플리케이션 배포가 파드 재시작을 어떻게 처리해야 하는지 결정하려면 애플리케이션 배포를 검토하세요.
1단계: 드라이버 설치
csi.enabled 플래그를 true로 설정한 Vault Secrets Operator Helm 차트를 설치해 CSI 드라이버를 모든 노드에서 실행되는 DaemonSet으로 배포해요.
$ helm install \
--version 1.0.0 \
--create-namespace \
--namespace vault-secrets-operator \
--set "csi.enabled=true" \
vault-secrets-operator \
hashicorp/vault-secrets-operator
추가 구성 옵션은 Helm 차트 문서를 참고하세요.
2단계: Vault 정책 만들기
CSI 드라이버가 시크릿을 가져오고/AppRole 시크릿 ID를 생성하게 하려면 Vault 정책을 만들어야 해요.
예를 들어 다음 정책은 CSI 드라이버가 Key/Value 플러그인에서 시크릿을 가져오게 해요.
path "example-kv/password" {
capabilities = ["read"]
}
path "example-kv-v2/data/api-key" {
capabilities = ["read"]
}
path "sys/license/status" {
capabilities = ["read"]
}
VSO를 Vault Enterprise나 HCP Vault Dedicated와 함께 사용할 때는 sys/license/status에 대한 읽기를 부여해야 해요. 그렇지 않으면 플러그인이 클러스터의 라이선스를 제대로 식별하지 못해요.
애플리케이션 파드가 Vault에 로그인해 시크릿을 독립적으로 가져올 수 있도록 CSI 드라이버가 AppRole 시크릿 ID를 생성하게 하려면, Vault 정책이 CSI 드라이버에 관련 역할에 대한 권한을 부여해야 해요.
예를 들어 다음 정책은 CSI 드라이버가 AppRole 플러그인으로 시크릿 ID를 생성하게 해요.
path "auth/approle/role/example-role/secret-id" {
capabilities = ["update"]
}
path "auth/approle/role/example-role/role-id" {
capabilities = ["read"]
}
정책을 Vault에 쓴 후에는, Vault Secrets Operator가 지원하는 어떤 인증 방식에서든 그 정책을 사용하는 역할을 만들 수 있어요.
예를 들어 Kubernetes 인증 방식과 함께 정책을 사용하려면:
$ vault write auth/kubernetes/role/example-auth-role \
bound_service_account_names=default \
bound_service_account_namespaces=default,vault-secrets-operator-system \
token_period=120 \
token_policies=csi-driver-policy \
audience=vault
3단계: 인증 커스텀 리소스 만들기
CSI 드라이버를 Vault에 인증하게 하려면 Vault Secrets Operator Helm 차트의 CRD(커스텀 리소스 정의)에 정의된 대로 VaultAuth와 VaultConnection 리소스를 만들어 클러스터에 적용해야 해요.
Vault Secrets Operator의 기존 인증 리소스를 참조하거나 완전히 새로운 리소스를 만들 수 있어요. 예:
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
name: default
namespace: vault-secrets-operator-system
spec:
vaultAuthGlobalRef:
name: default
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuthGlobal
metadata:
name: default
namespace: vault-secrets-operator-system
spec:
defaultAuthMethod: kubernetes
kubernetes:
audiences:
- vault
mount: kubernetes
role: example-auth-role
serviceAccount: example-service-account
tokenExpirationSeconds: 600
---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultConnection
metadata:
name: default
namespace: vault-secrets-operator-system
spec:
address: http://vault.vault.svc.cluster.local:8200
skipTLSVerify: false
더 자세한 리소스 예제는 Vault authentication에 대한 Vault Secrets Operator 가이드를 참고하세요.
4단계: CSISecrets 리소스 만들기
Vault와 애플리케이션 파드 사이에 시크릿을 안전하게 동기화하려면, CSI 드라이버 파드에 제공되는 정보를 나열하는 CSISecrets라는 커스텀 리소스를 만들어야 해요.
예를 들어 다음 리소스 정의는 하나의 CSISecrets 리소스를 만드는데, 이 리소스는:
- auth/approle에 마운트된 approle 인증 방식에서 my-app이라는 이름으로 구성된 역할의 시크릿 ID를 생성함.
- accessControl 필드의 정규 표현식 패턴에 따라 관련 CSISecrets 리소스를 사용할 수 있는 파드를 제한함.
- kv1에 마운트된 kv v1 시크릿 엔진에서 시크릿을 가져옴.
- kv2에 마운트된 kv v2 시크릿 엔진에서 시크릿을 가져옴.
apiVersion: secrets.hashicorp.com/v1beta1
kind: CSISecrets
metadata:
name: my-app-secrets
namespace: vault-secrets-operator-system
spec:
vaultAuthRef:
name: default
secrets:
vaultStaticSecrets:
- mount: kv1
path: app-api-key
type: kv-v1
- mount: kv2
path: app-api-key
type: kv-v2
version: 1 # KV 시크릿의 버전 -- 지정하지 않으면 최신 버전으로 기본
vaultAppRoleSecretIDs:
- role: my-app
mount: approle
wrapTTL: "30m"
ttl: "1h"
numUses: 2
accessControl:
serviceAccountPattern: "default"
namespacePatterns:
- "default"
podNamePatterns:
- "^my-app-"
syncConfig:
containerState:
namePattern: "^(app|sidecar)$"
추가 구성 옵션은 전체 CSISecrets API reference를 참고하세요.
5단계: 컨테이너에 볼륨 마운트
애플리케이션의 deployment 스펙을 업데이트해요.
- volumeMounts 필드에 새 CSISecrets 리소스를 추가해요.
- CSISecrets 리소스의 accessControl 스탠자에 시크릿 데이터에 접근할 수 있는 파드를 지정하는 정규 표현식을 정의해요.
예:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: default
labels:
app.kubernetes.io/component: my-app
spec:
selector:
matchLabels:
app.kubernetes.io/component: my-app
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/component: my-app
spec:
serviceAccountName: default
containers:
- name: app
image: my-app-image:latest
volumeMounts:
- name: csi-secrets
mountPath: /var/run/csi-secrets
- name: sidecar
image: my-app-sidecar-image:latest
volumeMounts:
- name: csi-secrets
mountPath: /var/run/csi-secrets
volumes:
- name: csi-secrets
csi:
driver: csi.vso.hashicorp.com
volumeAttributes:
csiSecretsName: my-app-secrets
csiSecretsNamespace: vault-secrets-operator-system
팁: 쿠버네티스 subPath 필드와 관련 파일 인덱스를 사용해 컨테이너가 접근할 수 있는 시크릿 파일을 제한할 수도 있어요. 예를 들어 다음 subPath는 첫 번째 approle 시크릿(app_role_0_wrap_info.json)으로의 접근만 제한합니다.
volumeMounts:
- name: csi-secrets
mountPath: /var/run/app_role_0_wrap_info.json
subPath: app_role_0_wrap_info.json
다음으로 새 구성을 푸시해 애플리케이션 파드 노드의 CSI 드라이버 파드가 요청에 응답하게 해요. 업데이트가 성공하면 kubelet이 CSISecrets 리소스의 모든 시크릿을 담은 볼륨을 게시합니다.
6단계: 파드가 시크릿에 적절히 접근하는지 확인
파드가 시작되면 구성된 마운트(예: /var/run/csi-secrets)의 파일을 검사해 관련 CSISecrets 리소스에 접근할 수 있는지 여부를 확인할 수 있어요.
추가 도움이 필요하면 troubleshooting 페이지를 참고하세요.