¿Odias los anuncios? Ir Sin publicidad Hoy 

Generador de ConfigMap y Secretos de Kubernetes

DatosDesarrolladorSeguridad

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

ConfigMap

Secreto

Nombre

Solo letras minúsculas, dígitos, '-' y '.' (RFC 1123).

Espacio de nombres

Deje vacío para omitir metadata.namespace y utilice el contexto actual de kubectl.

Tipo de Secreto

Determina el campo `type` del Secreto y las claves esperadas.

Codificar automáticamente en base64 los valores (data:)

Valores en texto plano (stringData:)

Datos clave/valor

Una línea KEY=value. Los valores pueden contener '='; solo el primer '=' separa la clave.

Etiquetas

Opcional. Una clave=valor por línea. Añadida bajo metadata.labels.

Anotaciones

Opcional. Una clave=valor por línea. Añadida bajo metadata.annotations.

Inmutable (no puede actualizarse después de su creación)

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Generador de ConfigMap y Secret de Kubernetes

Crea manifestos listos para kubectl de ConfigMap y Secret de Kubernetes a partir de una lista simple de pares clave=valor. El generador valida los nombres de recursos contra RFC 1123, codifica en base64 los valores de Secret para el campo y emite YAML limpio que puedes tuber directamente en data . kubectl apply -f -. Ningún dato abandona tu navegador.

Cómo Usar

Elige el tipo de recurso: ConfigMap para configuración no sensible o Secreto para credenciales, tokens y certificados.
Ingresa un nombre de recurso en minúsculas (RFC 1123) y, opcionalmente, un namespace.
Para Secrets, elige el tipo de secreto (Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, etc.) y decide si codificar automáticamente en base64 (data:) o mantenerlos en texto plano (stringData:).
Pega tus pares clave/valor, uno KEY=value por línea. Añade etiquetas y anotaciones si las necesitas.
Copia el YAML generado o descárgalo como un .yaml archivo listo para kubectl apply.

Características

ConfigMap y Secret en una sola herramienta – Alternar entre tipos de recursos sin perder tus entradas.
Codificación automática en base64 – Los valores de Secret se codifican con soporte completo de UTF-8, por lo que contraseñas y tokens con caracteres no ASCII se transfieren correctamente.
modo stringData – Salta la codificación cuando deseas un manifest editable por humanos; Kubernetes lo codificará automáticamente en el momento de la aplicación.
Todos los tipos estándar de Secret – Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, kubernetes.io/basic-auth, kubernetes.io/ssh-authy kubernetes.io/service-account-token.
Validación en tiempo real de RFC 1123 – Captura nombres, espacios de nombres y claves de datos inválidos antes kubectl apply los rechaza.
Etiquetas, anotaciones y bandera inmutable – Añade metadatos y opta por la bandera inmutable para recursos que nunca deben cambiar.
Citado YAML inteligente – Los valores que parecen números, booleanos o contienen caracteres especiales se codifican automáticamente; los valores de múltiples líneas usan escalares de bloque.
100% del lado del cliente – Las claves y valores nunca abandonan el navegador; nada se sube, registra o transmite.

 Preguntas frecuentes

¿Cuál es la diferencia entre un ConfigMap y un Secret en Kubernetes?

Los ConfigMap almacenan configuración no sensible como pares clave/valor simples, mientras que los Secrets están destinados para credenciales, tokens y otros materiales sensibles. Los valores de Secret se almacenan codificados en base64 y Kubernetes puede montarlos con permisos más estrictos, integrarlos con proveedores de cifrado en reposo y limitar qué nodos los reciben.
¿Por qué los valores de Secret de Kubernetes se codifican en base64?

La codificación en base64 permite que los datos binarios viajen de forma segura dentro de YAML/JSON sin romper la estructura ni producir caracteres inválidos. No es cifrado, por lo que cualquier persona con acceso de lectura al API del clúster puede decodificar los valores. La protección real proviene de RBAC, cifrado en reposo y registro de auditoría.
¿Cuándo debo marcar un ConfigMap o un Secret como inmutable?

Marca un ConfigMap o un Secret como inmutable cuando no esperas cambiarlo y deseas reducir la carga en el kubelet en clusters grandes. Los recursos inmutables omiten la actualización basada en monitoreo, por lo que el kubelet deja de realizar peticiones periódicas. El costo es que debes eliminar y recrear el recurso para cambiar un valor.
¿Cuál es la diferencia entre data y stringData en un manifest de Secret?

El campo data debe contener valores codificados en base64; el servidor API los almacena tal como están. El campo stringData acepta cadenas de texto UTF-8 simples que el servidor API codifica automáticamente en el momento de la creación o actualización. Si ambos están presentes, stringData gana para cualquier clave que se solapen. Usa stringData cuando creas secrets manualmente y data cuando integras con herramientas que ya codifican.