Kubernetes ConfigMaps e Secrets – Revisão para a Prova CKA

Se você está se preparando para a prova Certified Kubernetes Administrator (CKA), já deve ter percebido que ConfigMaps e Secrets são temas super importantes. Eles não só aparecem nas questões, mas também fazem parte do seu dia a dia trabalhando com clusters Kubernetes. Nos meus estudos, esses recursos foram desafiadores no começo, mas com a prática, tudo fez sentido.

Currículo Prova CKA
Currículo Prova CKA

Vamos explorar juntos como trabalhar com Kubernetes ConfigMaps e Secrets, entendendo como eles se aplicam a Pods, Deployments e à gestão de variáveis de ambiente (env) no Kubernetes. Iremos verificar todas as formas de criar e utilizar ConfigMaps e Secrets, usando manifestos e o formato imperativo. Este material vai te ajudar a revisar e dominar esses conceitos.


O que são ConfigMaps e Secrets?

ConfigMaps

Um ConfigMap é um recurso do Kubernetes que permite armazenar dados de configuração em formato de pares chave-valor. Pense nele como uma maneira de desacoplar as configurações da aplicação, permitindo que você altere configurações sem precisar modificar ou recriar os contêineres.

Exemplo de criação de um ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: meu-configmap
data:
  APP_NAME: "minha-aplicacao"
  APP_ENV: "producao"

Secrets

Os Secrets funcionam de maneira semelhante aos ConfigMaps, mas com um foco especial em dados sensíveis, como credenciais, tokens de acesso e senhas. Eles armazenam essas informações de forma codificada em Base64 para adicionar uma camada extra de proteção.

Exemplo de criação de um Secret:

apiVersion: v1
kind: Secret
metadata:
  name: meu-secret
data:
  DB_USER: YWRtaW4=  # "admin" em Base64
  DB_PASS: cGFzc3dvcmQ=  # "password" em Base64

Diferenças entre ConfigMaps e Secrets

CaracterísticaConfigMapsSecrets
Tipo de dados armazenadosDados de configuraçãoDados sensíveis
Forma de armazenamentoTexto puroCodificado em Base64
Proteção extraNãoSim, mais seguro
Uso comumVariáveis de ambiente, configurações geraisCredenciais, tokens, senhas

Como usar ConfigMaps e Secrets com Pods

Montando ConfigMaps em um Pod

Os ConfigMaps podem ser usados de diversas maneiras, como variáveis de ambiente ou arquivos montados em um volume.

Como variáveis de ambiente:

apiVersion: v1
kind: Pod
metadata:
  name: pod-com-configmap
spec:
  containers:
  - name: app
    image: nginx
    env:
    - name: APP_NAME
      valueFrom:
        configMapKeyRef:
          name: meu-configmap
          key: APP_NAME

Também é possível neste formato:

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
spec:
  containers:
    - name: simple-webapp-color
      image: simple-webapp-color
      ports:
        - containerPort: 8080
      envFrom:
        - configMapRef:
            name: app-config

Como volume montado:

apiVersion: v1
kind: Pod
metadata:
  name: pod-com-configmap-volume
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: meu-configmap

Outro exemplo:

# Injetando variáveis como arquivo num Volume
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never

Forma imperativa

Criar ConfigMaps de forma imperativa no Kubernetes é útil para quando você deseja realizar operações rápidas diretamente no terminal, sem criar arquivos YAML. Vou te mostrar como criar, utilizando exemplos práticos e trazendo algumas dicas importantes.

1. ConfigMap baseado em Strings

Você pode criar um ConfigMap com chaves e valores diretamente na linha de comando:

kubectl create configmap meu-configmap --from-literal=chave1=valor1 --from-literal=chave2=valor2
2. ConfigMap baseado em arquivos

Se você tiver um arquivo com configurações, pode usá-lo para criar o ConfigMap:

kubectl create configmap meu-configmap --from-file=meuarquivo.properties

Exemplo do arquivo meuarquivo.properties:

config.chave1=valor1
config.chave2=valor2
3. ConfigMap com Vários Arquivos

Você pode incluir múltiplos arquivos:

kubectl create configmap meu-configmap --from-file=arquivo1.properties --from-file=arquivo2.json
4. Montar ConfigMap como Volume

Crie um ConfigMap:

kubectl create configmap app-config --from-literal=app.env=prod --from-literal=db.url=localhost

Utilize-o no Pod:

volumes:
  - name: config-volume
    configMap:
      name: app-config
volumeMounts:
  - mountPath: /etc/config
    name: config-volume
Dicas:
  • Use kubectl describe configmap <nome-do-configmap> para verificar o conteúdo criado.
  • Para usar o ConfigMap em um Pod, referencie-o no spec.containers.envFrom ou monte-o como volume:
  envFrom:
  - configMapRef:
      name: meu-configmap
  • Use e abuse do comando kubectl create configmap -h, para obter exemplos e tirar dúvidas sobre o comando durante a prova CKA:
kubectl help
kubectl help

Montando Secrets em um Pod

Os Secrets também podem ser usados como variáveis de ambiente ou volumes.

Como variáveis de ambiente:

apiVersion: v1
kind: Pod
metadata:
  name: pod-com-secret
spec:
  containers:
  - name: app
    image: nginx
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: meu-secret
          key: DB_USER

Como volume montado:

apiVersion: v1
kind: Pod
metadata:
  name: pod-com-secret-volume
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: meu-secret

Forma imperativa

Para as Secrets, podemos efetuar os procedimentos usando a forma imperativa também, visando agilizar o processo.

Vou trazer alguns exemplos práticas e dicas bem legais.

1. Secret com Strings codificadas (Base64 Automático)

Crie Secrets diretamente com valores sensíveis:

kubectl create secret generic meu-secret --from-literal=senha=senha123 --from-literal=token=abc123
2. Secret baseado em Arquivo

Se você tiver arquivos contendo valores sensíveis:

kubectl create secret generic meu-secret --from-file=chave-privada=private.key --from-file=certificado=cert.pem
3. Secret do tipo Docker Registry

Use este comando para criar secrets específicos para autenticação em registries Docker:

kubectl create secret docker-registry meu-secret-docker \
  --docker-username=usuario \
  --docker-password=senha \
  --docker-email=meuemail@exemplo.com
4. Referenciar Secrets em Contêiner

Crie o Secret:

kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password=senha123

Use no Pod:

env:
  - name: DB_USER
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: username
  - name: DB_PASS
    valueFrom:
      secretKeyRef:
        name: password
Dicas importantes:
  • Valores de Secrets são codificados em Base64, mas não são criptografados. Ative a criptografia de Secrets para maior segurança.
  • Use secrets em um Pod via variáveis de ambiente:
  envFrom:
  - secretRef:
      name: meu-secret
  • Para Secrets, os valores são codificados em base64. Para decodificar:
echo "valor_codificado" | base64 --decode
  • Ao criar Secrets, evite usar valores sensíveis diretamente na linha de comando (pois ficam no histórico). Prefira usar arquivos:
# Melhor prática
echo -n "senha_segura" > senha.txt
kubectl create secret generic db-pass --from-file=senha.txt
rm senha.txt

Casos de Uso para a Prova CKA

Na prova CKA, você pode encontrar cenários que exigem:

  • Criação de ConfigMaps e Secrets para configurar um aplicativo.
  • Montagem desses recursos em Pods ou Deployments.
  • Atualização de valores sem a necessidade de recriar os Pods.

Utilização de ConfigMaps com blocos

Podemos ter alguns cenários onde os ConfigMaps vem com um formato parecido com este:

image
ConfigMap – Blocos

Temos chaves simples com valores simples, essas entradas são como propriedades de um arquivo de configuração. Cada chave está mapeada diretamente para um valor simples em texto.
No exemplo:

player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
  • player_initial_lives e ui_properties_file_name são as chaves.
  • Seus respectivos valores são "3" e "user-interface.properties".

Os valores também são apresentados no formato de arquivos de texto. O conteúdo de cada “arquivo” é armazenado em YAML usando a sintaxe de blocos (|).

Por exemplo:

game.properties: |
  enemy.types=aliens,monsters
  player.maximum-lives=5    
user-interface.properties: |
  color.good=purple
  color.bad=yellow
  allow.textmode=true
  • As chaves game.properties e user-interface.properties representam “arquivos virtuais” cujo conteúdo é listado após o operador |.
  • Esse conteúdo pode ser montado diretamente em um pod como arquivos reais ou lido como variáveis de ambiente.

Criação de Secrets de forma imperativa

Durante a prova CKA (Certified Kubernetes Administrator), criar Secrets de forma imperativa é essencial para economizar tempo. Aqui estão alguns exemplos de comandos que você pode usar para criar Secrets de maneira rápida e eficaz:

  kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
  kubectl create secret generic db-user --from-literal=db-username='db-admin'

Resultado esperado:

image
image

Agora é possível criar um Pod que vai utilizar estas Secrets como variáveis de ambiente, conforme a imagem abaixo:

image
image

Aplicando o Pod na prática e acompanhando o Pod via kubectl get pods:

image
image

Manifesto de referencia:

apiVersion: v1
kind: Pod
metadata:
  name: envvars-multiple-secrets
spec:
  containers:
  - name: envars-test-container
    image: nginx
    env:
    - name: BACKEND_USERNAME
      valueFrom:
        secretKeyRef:
          name: backend-user
          key: backend-username
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-user
          key: db-username

Validando a existência das variáveis com as Secrets, utilizando o comando kubectl describe pod envvars-multiple-secrets:

image
image

Dicas para a prova CKA

Aqui estão algumas dicas que podem te ajudar:

  1. Memorize os comandos essenciais:
    • Criar um ConfigMap diretamente via linha de comando: kubectl create configmap meu-configmap --from-literal=APP_NAME=minha-aplicacao
    • Criar um Secret: kubectl create secret generic meu-secret --from-literal=DB_USER=admin --from-literal=DB_PASS=password
  2. Pratique a aplicação de YAMLs: Os YAMLs personalizados são fundamentais no exame.
  3. Entenda como verificar os dados:
    • Verificar ConfigMaps: kubectl describe configmap meu-configmap
    • Verificar Secrets (dados decodificados): kubectl get secret meu-secret -o yaml | grep 'data' | base64 -d
  4. Estude como montar ConfigMaps e Secrets em Deployments. Isso é muito comum em questões da prova CKA.

Perguntas Frequentes (FAQs)

1. Posso atualizar um ConfigMap sem reiniciar os Pods?

Sim, mas os Pods não capturam automaticamente as alterações. Uma solução é reiniciar os Pods ou configurar volumes que suportem hot reload.

2. Secrets são realmente seguros?

Secrets adicionam uma camada extra de segurança, mas não são criptografados por padrão. Você pode habilitar a criptografia etcd para maior segurança.

3. Qual a diferença entre usar um Secret como volume ou como variável de ambiente?

  • Volume: útil para armazenar arquivos sensíveis, como certificados.
  • Variável de ambiente: Melhor para credenciais simples ou tokens.

Conclusão

ConfigMaps e Secrets são ferramentas poderosas e indispensáveis no Kubernetes. Compreender como usá-los vai te ajudar não só na prova CKA, mas também na sua rotina no trabalho como DevOps/SRE. Espero que este guia tenha esclarecido os pontos principais e dado confiança para aplicar esse conhecimento.

Se você tiver alguma dúvida ou quiser compartilhar sua experiência, deixe um comentário ou leia outros artigos no meu blog!

Compartilhe / Share
Fernando Müller Junior
Fernando Müller Junior

Eu sou o Fernando Müller, um Tech Lead SRE com 16 anos de experiência em TI, atualmente eu trabalho na Appmax, uma fintech localizada no Brasil. Apaixonado por trabalhar com arquiteturas e aplicações Cloud Native, ferramentas Open Source e tudo que existe no mundo SRE, sempre procurando se desenvolver e aprender constantemente(Lifelong learning), atuando em projetos inovadores!

Artigos: 44

Receba as notícias por email / Receive news by email

Insira seu endereço de e-mail abaixo e assine nossa newsletter / Enter your email address below and subscribe to our newsletter

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *