❓

[CKA] 30. Configure Secrets

Date

2025/01/01

Secrets

ConfigMap은 일반 텍스트 형식으로 Configuration 데이터를 저장한다. 때문에 데이터베이스 구성 같은 민감 정보를 다룰 때 호스트 네임과 유저 네임을 ConfigMap에 구성하는 것은 괜찮지만 패스워드를 저장하기엔 적절하지 않다. Secret은 패스워드나 키 같은 민감 정보를 저장하는 데 사용되며, 데이터를 인코딩된 형식으로 저장한다. ConfigMap과 비슷하며, ‘Create Secret’, ‘Inject into Pod’ 두 단계를 가진다.

Create Secrets

Imperative

kubectl create secret generic <secret-name> --from-literal=<key>=<value>

# kubectl create secret generic \
#		app-secret --from-literal=DB_Host=mysql \
# 						 --from-literal-DB_User=root \
# 						 --from-literal-DB_Password=passwrd
Bash
복사

•

--from-literal: 명령 자체에서 키 값 쌍을 지정하는데 사용되는 옵션

kubectl create secret generic <secret-name> --from-file=<path-to-file>
Bash
복사

Declarative

Secret에서 민감 데이터는 인코딩된 포맷으로 저장한다. 데이터를 일반 텍스트로 명시하면 안전하지 않게 때문에 명령적 접근으로 Secret을 만들 때 인코딩된 형식의 값을 지정해야 한다.

Linux에서 echo -n 을 실행하면 변환시키고자 하는 텍스트가 출력된다

$ echo -n 'mysql' | base64
bXlzcWw=

$ echo -n 'root' | base64
cm9vdA==

$ echo -n 'passwrd' | base64
cGFzd3Jk
Bash
복사

# secret-data.yaml
apiVersion: v1
kind: Secret
metadata:
	name: app-secret
data:
	DB_Host: bXlzcWw=
	DB_User: cm9vdA==
	DB_Password: cGFzd3Jk
YAML
복사

View Secrets

생성된 secrets를 확인하기 위해 kubectl get secrets 명령을 사용할 수 있다. kubectl describe secrets 명령을 사용하면 속성값을 확인할 수 있지만, key에 대응되는 value들을 확인 할 수는 없다.

따라서 값을 확인하기 위해서는 yaml 포맷으로 secret을 확보해야 한다.

kubectl get secret app-secret -o yaml

Decode Secrets

값을 디코딩하기 위해서는 인코딩에 사용했던 base64 커맨드를 사용하면 된다

$ echo -n 'bXlzcWw=' | base64 --decode
mysql
Bash
복사

Inject into Pod

Pod의 환경 변수를 삽입하기 위해 컨테이너에 envFrom이라는 속성을 추가한다. envFrom은 list로 필요한만큼 많은 환경 변수를 설정할 수 있다. envFrom.secretRef.name의 값으로 생성한 Secret의 이름을 입력한다.

# pod-definition.yaml
apiVersion: v1
kind: Pod
metadata:
	name: simple-webapp-color
spec:
	containers:
	- name: simple-webapp-color
		image: simple-webapp-color
		ports:
			- containerPort: 8080
		envFrom:
			- secretRef:
					name: app-secret
YAML
복사

Secrets in Pods

Secret은 Pod에 환경 변수로 주입할 수 있고, 단일 환경 변수 주입도 가능하며 파일로서 전체 Secret을 볼륨에 넣을 수도 있다.

ENV

envFrom:
	- secretRef:
			name: app-secret
YAML
복사

SINGLE ENV

env:
	- name: DB_Password
		valueFrom:
			secretKeyRef:
				name: app-secret
				key: DB_Password
YAML
복사

VOLUME

volumes:
- name: app-secret-volume
	secret:
		secretName: app-secret
YAML
복사

•

Pod의 Volume으로 Secret이 주입되면 Secret의 각각의 속성은 value를 콘텐츠로 하는 파일로 생성된다.

$ ls /opt/app-secrets-volumes
DB_Host    DB_Password    DB_User

$ cat /opt/app-secrets-volumes/DB_Password
passwrd
Bash
복사

How to handle

•

Secret은 Secret이 필요한 Pod가 있을 때 해당 Pod의 Node로 전송된다.

•

Kubelet은 Secret을 tmpfs에 저장하여 디스크 저장소에 기록되지 않도록 한다.

•

Secret에 의존하던 Pod가 삭제되면 kubelet은 해당 secret 데이터를 로컬에서 삭제한다.

Note on Secrets

Secrets are not Encrypted. Only encoded.

Secret은 암호화된 것이 아니라 인코딩된 것일 뿐이기 때문에 누구든 파일을 확인할 수 있고 디코딩하여 데이터를 확인할 수 있다.

따라서 Github 같은 SCM에 푸시할 때 Secret 파일을 함께 푸시하면 안된다.

Secrets are not encrypted in ETCD

Secret은 ETCD에 저장되는데 기본적으로 ETCD는 데이터를 암호화하지 않는다. 따라서 보안성을 위해 암호화를 사용하는 것을 고려해야 한다.

Encrypting Confidential Data at Rest

All of the APIs in Kubernetes that let you write persistent API resource data support at-rest encryption. For example, you can enable at-rest encryption for Secrets. This at-rest encryption is additional to any system-level encryption for the etcd cluster or for the filesystem(s) on hosts where you are running the kube-apiserver. This page shows how to enable and configure encryption of API data at rest. Note:This task covers encryption for resource data stored using the Kubernetes API.

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

Anyone able to create pods/deployments in the same namespace can access the secrets

같은 네임스페이스에서 Pod를 만들 수 있는 사람은 누구나 Secret에 접근이 가능하기 때문에 RBAC(역할 기반 액세스 제어)을 구성하여 액세스 제한을 두어야 한다.

Consider third-party secrets store providers

AWS, Azure, GCP, Valut 등의 Provider를 사용하면 Secret이 ETCD가 아닌 외부에 저장되고 보안 처리가 되기 때문에 사용하는 것을 고려하는 것이 좋다.

Secret Store CSI Driver Tutorial | Kubernetes Secrets | AWS Secrets Manager | KodeKloud

Dive deep into the world of Kubernetes security with our comprehensive guide to Secret Store CSI Driver. Discover why this tool is essential for safeguarding sensitive information, learn how it compares to alternatives like ESO and Sealed Secrets, and master the process of setting it up for your Kubernetes cluster. With insightful demos showcasing the creation of secrets in AWS Secret Manager and the seamless integration of Secret Store CSI Driver, this video is your ultimate resource for enhancing security in your DevOps environment. Join us on this journey to strengthen your Kubernetes security posture and protect your valuable data. 🚀Grab Your Black Friday Offers Now: https://kode.wiki/3CzuOnc ⬇️Below are the topics we are going to discuss in this video: 00:00 - Introduction 00:48 - Why do we need Secret Store CSI Driver? 03:03 - What is Secret Store CSI Driver? 04:01- Secret Store CSI Driver vs ESO vs Sealed Secrets 05:25 - How does Secret Store CSI Driver works? 08:14 - Demo - Creating Secret in AWS Secret Manager 09:30 - Demo - Setting up Secret Store CSI Driver for Kubernetes Cluster 30:56 - Conclusion ✅Start your Kubernetes Career Now - https://bit.ly/KubernetesLearningPath Check out our learning paths at KodeKloud to get started: ▶️ Cloud Computing: https://kode.wiki/CloudLearningPath_YT ▶️ Kubernetes: https://bit.ly/KubernetesLearningPath ▶️AWS: https://kode.wiki/awslearningpath_yt ▶️Azure: https://kode.wiki/azurelearningpath_yt ▶️Google Cloud Platform: https://kode.wiki/GCPlearningpath_YT ▶️ Linux: https://bit.ly/LinuxLearningPath ▶️ DevOps Learning Path: https://bit.ly/DevOpsLearningPath-YT #Kubernetes #DevOps #SecretStoreCSIDriver #K8sSecurity #AWS #sealedsecrets #awssecrets #DevOpsTools #CyberSecurity #CloudComputing #kodekloud For more updates on courses and tips, follow us on: 🌐 Website: https://kodekloud.com/ 🌐 LinkedIn: https://www.linkedin.com/company/kodekloud/ 🌐 Twitter: https://twitter.com/KodeKloudHQ 🌐 Facebook: https://www.facebook.com/KodeKloudHQ 🌐 Instagram: https://www.instagram.com/kodekloud/ 🌐 Blog: https://kodekloud.com/blog/

https://www.youtube.com/watch?v=MTnQW9MxnRI