data frente a stringData en un Secret de Kubernetes: cuándo se necesita Base64

data frente a stringData en un Secret de Kubernetes: cuándo se necesita Base64

Los campos data y stringData de un Secret de Kubernetes representan los mismos valores lógicos, pero son interfaces de escritura distintas. data espera cadenas codificadas en Base64. stringData acepta texto normal y deja que el servidor de la API de Kubernetes lo codifique.

La diferencia importa al escribir un manifiesto, revisar uno existente o decidir si necesitas una herramienta local de Base64. Ninguno de los dos campos es un límite de seguridad: Base64 es codificación, no cifrado.

La diferencia práctica

Usa data cuando el valor ya esté serializado para la API de Secret:

apiVersion: v1
kind: Secret
metadata:
  name: credenciales-app
type: Opaque
data:
  username: YWRtaW4=
  password: c2FtcGxlLXBhc3M=

Usa stringData al escribir valores literales y dejar que Kubernetes codifique el contenido durante la operación con la API:

stringData:
  username: admin
  password: sample-pass

La documentación de Secrets de Kubernetes describe stringData como una forma cómoda de proporcionar valores sin codificar. También advierte que stringData no funciona bien con server-side apply, así que comprueba tu método de despliegue antes de adoptarlo.

Qué campo elegir

stringData suele ser la opción más legible para un manifiesto escrito a mano y aplicado por un flujo compatible. Mantiene el origen comprensible y evita copiar manualmente el resultado codificado.

data resulta útil cuando:

• otro sistema ya genera la forma serializada del Secret;
• inspeccionas o editas un manifiesto existente que usa data;
• tus herramientas esperan valores codificados;
• necesitas conservar bytes en lugar de asumir una representación textual.

No guardes credenciales reales en un repositorio solo porque estén bajo data. Cualquiera que pueda leer el manifiesto puede decodificarlas. Kubernetes trata el acceso y la distribución del Secret como asuntos de seguridad separados de su representación YAML.

Codificar o decodificar localmente

Si un manifiesto contiene un valor bajo data, puedes decodificar una copia local para saber qué representa. Si necesitas crear un valor para data, codifica localmente el valor original y pega solo el resultado en el manifiesto de trabajo.

TextForge puede codificar o decodificar texto en el navegador sin enviarlo a un servidor de Wendygo. Usa una copia de trabajo, revisa el resultado y conserva la credencial original en su entorno seguro. Si vas a compartir el manifiesto, ScrubForge es más adecuado: sanea primero la copia, en lugar de limitarte a codificar el secreto.

Lista breve de decisión

1. ¿Escribes un Secret nuevo desde texto literal? Considera stringData después de comprobar tu método de aplicación.
2. ¿Editas un campo data existente? Decodifica solo una copia local cuando haga falta inspeccionarlo.
3. ¿Tu pipeline exige data? Codifica localmente y valida el YAML resultante.
4. ¿El manifiesto saldrá de tu entorno seguro? Elimina o sustituye las credenciales antes de compartirlo.
5. ¿Una credencial ya pudo quedar expuesta? Rótala; codificar o sanear no deshace la exposición.

Consulta la guía de seguridad de Secrets de Kubernetes junto con la política de acceso y gestión de secretos de tu clúster.

Preguntas frecuentes

¿Los valores de data necesitan Base64?

Sí. Los valores de data se serializan como cadenas Base64. stringData acepta texto normal y Kubernetes lo codifica al crear o actualizar.

¿Debo usar data o stringData?

Usa stringData para texto literal cuando tu flujo lo admita. Usa data cuando tus herramientas requieran la representación serializada o trabajes con un manifiesto codificado existente.

¿Base64 protege un Secret?

No. Es codificación reversible, no cifrado. Protege el manifiesto, el acceso al clúster y el repositorio.