Anúncios incomodam? Ir Sem anúncios Hoje 

Gerador de ConfigMap e Segredo do Kubernetes

DadosDesenvolvedorSegurança

[iotools_kubernetes_configmap_secret_generator]

Guia

Gerador de ConfigMap e Secret do Kubernetes

Crie manifestos de ConfigMap e Secret do Kubernetes prontos para kubectl a partir de uma simples lista de pares CHAVE=VALOR. O gerador valida os nomes de recursos conforme o RFC 1123, codifica os valores de Secret em base64 para o campo e emite YAML limpo que pode ser direcionado imediatamente para data . kubectl apply -f -. Nenhum dado sai do seu navegador.

Como usar

Escolha o tipo de recurso: ConfigMap para configuração não sensível ou Secret para credenciais, tokens e certificados.
Insira um nome de recurso em minúsculas (RFC 1123) e, opcionalmente, um namespace.
Para Secrets, escolha o tipo de secret (Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, etc.) e decida se deseja codificar automaticamente os valores em base64 (data:) ou mantê-los em texto plano (stringData:).
Cole seus pares chave/valor, um por linha. Adicione rótulos e anotações se necessário. KEY=value Copie o YAML gerado ou baixe-o como um
arquivo pronto para .yaml ConfigMap e Secret em uma única ferramenta kubectl apply.

Características

– Alternar entre os tipos de recurso sem perder seus dados de entrada. Codificação automática em base64
– Os valores de Secret são codificados com suporte completo ao UTF-8, permitindo que senhas e tokens com caracteres não-ASCII sejam transmitidos corretamente. modo stringData
– Pule a codificação quando desejar um manifesto editável por humanos; o Kubernetes codificará automaticamente a base64 durante a aplicação. Todos os tipos padrão de Secret
Validação em tempo real do RFC 1123 – Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, kubernetes.io/basic-auth, kubernetes.io/ssh-authe, e kubernetes.io/service-account-token.
– Capture nomes, namespaces e chaves de dados inválidos antes os rejeite. kubectl apply Rótulos, anotações e bandeira imutável
– Adicione metadados e opte pela bandeira imutável para recursos que nunca devem mudar. Citação inteligente do YAML
– Valores que parecem números, booleanos ou contêm caracteres especiais são automaticamente citados; valores multilinhas usam escalares de bloco. – Chaves e valores nunca deixam o navegador; nada é enviado, registrado ou transmitido.
100% do lado do cliente Qual a diferença entre um ConfigMap e um Secret no Kubernetes?

 Perguntas frequentes

Os ConfigMaps armazenam configurações não sensíveis como pares chave/valor simples, enquanto os Secrets são destinados a credenciais, tokens e outros materiais sensíveis. Os valores de Secret são armazenados em codificação base64 e o Kubernetes pode montá-los com permissões mais restritas, integrá-los a fornecedores de criptografia em repouso e limitar quais nós os recebem.

Por que os valores de Secret do Kubernetes são codificados em base64?
A codificação em base64 permite que dados binários viajem de forma segura dentro de YAML/JSON sem quebrar a estrutura ou gerar caracteres inválidos. Não é criptografia, então qualquer pessoa com acesso de leitura ao API do cluster pode ainda decodificar os valores. A proteção real vem de RBAC, criptografia em repouso e registros de auditoria.

Quando devo tornar um ConfigMap ou um Secret imutável?
Marque um ConfigMap ou um Secret como imutável quando não esperar mudá-lo e desejar reduzir a carga do kubelet em clusters grandes. Recursos imutáveis poupam atualizações baseadas em watch, então o kubelet para emitir GETs periódicos. A desvantagem é que você deve excluir e recarregar o recurso para alterar um valor.

Qual a diferença entre "data" e "stringData" em um manifesto de Secret?
O campo "data" deve conter valores codificados em base64; o servidor API os armazena assim. O campo "stringData" aceita strings em UTF-8 simples que o servidor API codifica automaticamente durante a criação ou atualização. Se ambos estiverem presentes, "stringData" prevalece para qualquer chave que se sobreponha. Use "stringData" quando criar secrets manualmente e "data" quando integrar com ferramentas que já codificam.

foi adicionado em 14 de junho de 2026