Por qué necesitás un generador de secrets Kubernetes
Crear secrets manualmente en Kubernetes implica riesgos: tu historial de bash guarda las credenciales en texto plano, los logs del sistema pueden exponerlas, y la codificación base64 manual es propensa a errores. Este generador produce valores seguros que podés inyectar directamente en tus manifests sin tocar la terminal.
Los secrets generados acá son criptográficamente aleatorios usando fuentes del sistema operativo, no pseudo-aleatorios predecibles. Cada ejecución produce valores únicos aptos para entornos de producción, desde passwords de bases de datos hasta tokens de API de terceros.
Casos reales de uso: configurar PostgreSQL en un StatefulSet, integrar servicios externos vía ConfigMaps, autenticar registries privados de Docker, o rotar credenciales después de un incidente de seguridad.
Cómo aplicar secrets en tus manifests
Una vez generado el secret, creás un archivo YAML tipo my-secret.yaml con la estructura básica: apiVersion: v1, kind: Secret, metadata.name, y el campo data con tus claves base64-encoded. Aplicás con kubectl apply -f my-secret.yaml.
Para consumirlo desde un Pod, lo montás como volumen (volumes.secret.secretName) o lo inyectás como variable de entorno (valueFrom.secretKeyRef). La segunda opción es más directa para credenciales simples; la primera es mejor para certificados TLS o archivos de configuración complejos.
Error común: olvidar que base64 no es encriptación. Si tu cluster no tiene encryption-at-rest habilitado (EncryptionConfiguration), los secrets se guardan en plain text en etcd. Habilitá siempre el cifrado en producción.
Tipos de secrets y cuándo usar cada uno
Kubernetes reconoce Opaque (genérico), kubernetes.io/tls (certificados), kubernetes.io/dockerconfigjson (registry), y kubernetes.io/service-account-token. El 90% de tus secrets serán Opaque: passwords, API keys, tokens custom.
Para registries privados, usá docker-registry type con kubectl create secret docker-registry o generá el JSON de .dockerconfigjson manualmente. Los TLS secrets esperan tls.crt y tls.key como claves obligatorias.
Tip práctico: separá secrets por scope. Uno por base de datos, otro para APIs externas. Así rotás credenciales sin afectar servicios no relacionados. Usá labels y namespaces para aislar secrets críticos del resto del cluster.
Rotación y gestión de secrets en producción
Un secret sin política de rotación es una bomba de tiempo. Establecé ventanas de rotación según criticidad: cada 30 días para admin passwords, cada 90 para tokens de lectura. Automatizá con CronJobs que llamen a APIs externas (Vault, AWS Secrets Manager) y actualicen los secrets vía kubectl patch.
Herramientas como Sealed Secrets o External Secrets Operator te permiten almacenar secrets encriptados en Git y sincronizarlos con el cluster. Así auditás cambios sin exponer valores reales. Nunca commitees secrets sin cifrar, ni siquiera en repos privados.
Checklist de seguridad:
- RBAC estricto (solo ServiceAccounts necesarios leen secrets)
- Encryption-at-rest habilitado en etcd
- Logs de API server no imprimen secret values
- Secrets con TTL donde sea posible (cert-manager para TLS)