Introducción
Las aplicaciones a menudo requieren valores que no deben incluirse directamente en una imagen de contenedor o en un manifiesto de texto plano, como contraseñas, tokens o credenciales de bases de datos. Los Secrets de Kubernetes almacenan este tipo de configuración sensible como un objeto independiente y permiten que los Pods los consuman al iniciarse.
En este laboratorio, creará un Secret, inspeccionará cuidadosamente sus datos codificados, lo conectará a un Pod de aplicación, actualizará el Secret y volverá a crear el Pod para que la aplicación lea los nuevos valores. Este laboratorio se centra en el flujo de trabajo fundamental de los Secrets. En laboratorios posteriores, se practicará la configuración detallada de variables de entorno y montajes de configuración basados en archivos.
Preparar un espacio de nombres para practicar con Secrets
En este paso, preparará un espacio de nombres (namespace) limpio para practicar con Secrets.
Comience en /home/labex/project. Escribirá un manifiesto de Pod en este directorio.
mkdir -p /home/labex/project
cd /home/labex/project
Compruebe que el servidor de la API de Kubernetes sea accesible. Si la máquina virtual acaba de iniciarse y el nodo aún no está listo, espere unos segundos y vuelva a ejecutar el comando.
kubectl get nodes --request-timeout=5s
La salida esperada incluye:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Espere a que el Pod de red del clúster esté listo (Ready) antes de crear objetos de aplicación.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Salida esperada:
pod/calico-node-... condition met
Cree un espacio de nombres llamado ckad-prep-secrets:
kubectl create namespace ckad-prep-secrets
Establezca este espacio de nombres como el contexto actual:
kubectl config set-context --current --namespace=ckad-prep-secrets
Confirme el espacio de nombres actual:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Salida esperada:
ckad-prep-secrets
Crear e inspeccionar un Secret
En este paso, creará un Secret que almacene los ajustes de conexión a una base de datos para una pequeña aplicación.
El comando kubectl create secret generic crea un Secret de tipo opaco (opaque). generic significa que Kubernetes no asigna un significado especial predefinido a las claves. Cada flag --from-literal añade un par clave-valor al Secret.
kubectl create secret generic db-credentials \
--from-literal=DB_USER=orders-app \
--from-literal=DB_PASSWORD=dev-password-123 \
--from-literal=DB_NAME=orders
Salida esperada:
secret/db-credentials created
Inspeccione el resumen del Secret:
kubectl get secret db-credentials
Salida esperada:
NAME TYPE DATA AGE
db-credentials Opaque 3 ...
Visualice el Secret en formato YAML. Kubernetes almacena los valores bajo data como cadenas codificadas en base64, por lo que no debería esperar ver la contraseña original en esta salida.
kubectl get secret db-credentials -o yaml
La salida esperada incluye:
data:
DB_NAME: b3JkZXJz
DB_PASSWORD: ...
DB_USER: b3JkZXJzLWFwcA==
type: Opaque
La codificación base64 no es cifrado. Cualquier persona que pueda leer el objeto Secret puede decodificar sus valores. Decodifique solo el nombre de usuario aquí para ver cómo funciona la representación sin imprimir la contraseña.
kubectl get secret db-credentials -o 'jsonpath={.data.DB_USER}' | base64 --decode; echo
Salida esperada:
orders-app
Configurar un Pod a partir del Secret
En este paso, iniciará un Pod que lee el Secret como variables de entorno.
El campo envFrom.secretRef importa todas las claves de un Secret al entorno del contenedor. Esto es similar al patrón de ConfigMap del laboratorio anterior, pero los valores provienen de un objeto Secret. El comando en este Pod imprime el nombre de usuario y el nombre de la base de datos, y luego confirma que se cargó una contraseña. No imprime la contraseña en sí.
Cree secret-reader-pod.yaml:
cat > secret-reader-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: secret-reader
labels:
app: secret-reader
spec:
terminationGracePeriodSeconds: 0
containers:
- name: reader
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo user=${DB_USER}; echo database=${DB_NAME}; if [ -n "${DB_PASSWORD}" ]; then echo password-loaded; fi; sleep 3600'
envFrom:
- secretRef:
name: db-credentials
EOF
Aplique el manifiesto del Pod:
kubectl apply -f secret-reader-pod.yaml
Salida esperada:
pod/secret-reader created
Espere a que el Pod esté listo:
kubectl wait --for=condition=Ready pod/secret-reader --timeout=120s
Salida esperada:
pod/secret-reader condition met
Lea los registros (logs) del Pod. La aplicación confirma que los valores del Secret estaban disponibles, pero el valor de la contraseña no se muestra.
kubectl logs secret-reader -c reader
Salida esperada:
user=orders-app
database=orders
password-loaded
Actualizar el Secret y volver a crear el Pod
En este paso, actualizará el Secret y volverá a crear el Pod para que el contenedor reciba los nuevos valores.
El entorno de un contenedor se captura cuando este se inicia. Si un Secret se consume como variables de entorno, actualizar el objeto Secret no reescribe el entorno dentro de un contenedor que ya está en ejecución. Inicie un nuevo Pod cuando la aplicación deba leer valores actualizados del Secret.
Aplique un parche (patch) al Secret con un nuevo usuario y contraseña:
kubectl patch secret db-credentials --type merge --patch '{"stringData":{"DB_USER":"orders-worker","DB_PASSWORD":"rotated-password-456","DB_NAME":"orders"}}'
Salida esperada:
secret/db-credentials patched
Confirme el nombre de usuario actualizado decodificando solo DB_USER:
kubectl get secret db-credentials -o 'jsonpath={.data.DB_USER}' | base64 --decode; echo
Salida esperada:
orders-worker
Elimine el Pod antiguo:
kubectl delete pod secret-reader
La salida esperada incluye:
pod "secret-reader" deleted
Vuelva a crear el Pod a partir del mismo manifiesto y espere a que esté listo:
kubectl apply -f secret-reader-pod.yaml
kubectl wait --for=condition=Ready pod/secret-reader --timeout=120s
Salida esperada:
pod/secret-reader created
pod/secret-reader condition met
Lea los registros de nuevo. El nuevo Pod ahora ve el usuario actualizado del Secret y sigue evitando imprimir la contraseña sin procesar.
kubectl logs secret-reader -c reader
Salida esperada:
user=orders-worker
database=orders
password-loaded
Resumen
Ha creado un Secret de Kubernetes, inspeccionado sus datos codificados, decodificado una clave no sensible para comprender la representación, conectado el Secret a un Pod de aplicación y vuelto a crear el Pod tras actualizar el Secret. También ha practicado un hábito importante para configuraciones sensibles: verificar que la aplicación recibió la contraseña sin imprimir el valor de la misma en los registros.
