Actividad 9: Create a new Secret named db-secret-xxdf with the data given. Secret Name: db-secret-xxdf, DB_HOST=sql01, DB_User=root, DB_Password=password123.
Bastante sencillo solo revise las opciones de create secret.
Veo que hay tres tipos de secretos, generic, dockerregistry, y tls. Para fines de este ejercicio use generic. Asumiria asi como en otras plataformas que se pueden crear tipos personalizados de secretos y reutilizar, pero no me interesa profundizar en ese tipo de teoria todavia.
kubectl create secret generic -h
Me dio basicamente las mismas opciones que el configmap, de momento me centre en la bandera –from-literal
kubectl create secret generic db-secret-xyz –from-literal=DB_HOST=sql01 –from-literal=DB_User=root –from-literal=DB_Paasword=password123
simplemente con los comandos exploradores comunes se puede validar
kubectl describe secret db-secret-xyz
kubectl get secret db-secret-xyz

Ahora metodo para usar un archivo de configuracion.
En general bastante sencillo, todo en un solo archivo usando —
apiVersion: v1
kind: Secret
metadata:
name: my-secret2
type: opaque
stringData:
username: moises
password: chirinos
---
apiVersion: v1
kind: Secret
metadata:
name: basic-auth-secret
type: kubernetes.io/basic-auth
data:
username: bXl1c2Vy
password: bXlwYXNzd29yZA==
---
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
username: YWRtaw4=
password: MWYyZDFlMmU2N2Rm
---
apiVersion: v1
kind: Pod
metadata:
name: pod-con-env
spec:
containers:
- name: app
image: busybox
command: ["sh", "-c", "env && sleep 3600"]
env:
- name: BASIC_USER
valueFrom:
secretKeyRef:
name: my-secret
key: username
- name: BASIC_PASS
valueFrom:
secretKeyRef:
name: my-secret
key: password
Cosas interesantes.
- Es importante el espacio despues de cada : (o genera errores del yaml)
- Hay varios tipos como Opaque / basic-auth , lo mas generico es Opaque
- Hay varios tipos de como enviar la data.
- data: permite guardar los valores como base64 para evitar problemas de caracteres.
- stringData: permite guardar texto literal.
Conclusiones:
- Los secretos son muy parecidos a los configmap.
- Los secretos no estan protegidos por defecto. Alguien con acceso al cluster puede verlos en el etcd. Y hay algunos consejos de configuracion por defecto en la pagina de K8. https://kubernetes.io/docs/concepts/configuration/secret/
- Los secretos se pueden cargar desde archivos del entorno o dotenv para evitar escribirlos en los repositorios.
- Tambien se pueden consumir de otras fuentes.
- Los secretos en un pod o deployment similar a los configmap se llama usando ‘valueFrom’ pero el tipo es ‘secretKeyRef’