Introdução
As aplicações frequentemente necessitam de valores que não devem ser colocados diretamente em uma imagem de container ou em um manifesto simples, como senhas, tokens ou credenciais de banco de dados. Os Secrets do Kubernetes armazenam esse tipo de configuração sensível como um objeto separado e permitem que os Pods os consumam no momento da inicialização.
Neste laboratório, você criará um Secret, inspecionará cuidadosamente seus dados codificados, conectá-lo-á a um Pod de aplicação, atualizará o Secret e recriará o Pod para que a aplicação leia os novos valores. Este laboratório foca no fluxo de trabalho principal de Secrets. Laboratórios futuros abordarão configurações mais detalhadas de variáveis de ambiente e montagens de arquivos.
Preparar um Namespace para Prática de Secrets
Nesta etapa, você preparará um namespace limpo para praticar com Secrets.
Comece em /home/labex/project. Você escreverá um manifesto de Pod neste diretório.
mkdir -p /home/labex/project
cd /home/labex/project
Verifique se o servidor da API do Kubernetes está acessível. Se a VM acabou de iniciar e o nó ainda não está pronto, aguarde alguns segundos e execute o comando novamente.
kubectl get nodes --request-timeout=5s
A saída esperada inclui:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Aguarde até que o Pod de rede do cluster esteja pronto (Ready) antes de criar objetos de aplicação.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Saída esperada:
pod/calico-node-... condition met
Crie um namespace chamado ckad-prep-secrets:
kubectl create namespace ckad-prep-secrets
Defina este namespace como o namespace do contexto atual:
kubectl config set-context --current --namespace=ckad-prep-secrets
Confirme o namespace atual:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Saída esperada:
ckad-prep-secrets
Criar e Inspecionar um Secret
Nesta etapa, você criará um Secret que armazena configurações de conexão de banco de dados para uma pequena aplicação.
O comando kubectl create secret generic cria um Secret opaco (opaque). generic significa que o Kubernetes não atribui um significado especial embutido às chaves. Cada flag --from-literal adiciona um par chave-valor ao Secret.
kubectl create secret generic db-credentials \
--from-literal=DB_USER=orders-app \
--from-literal=DB_PASSWORD=dev-password-123 \
--from-literal=DB_NAME=orders
Saída esperada:
secret/db-credentials created
Inspecione o resumo do Secret:
kubectl get secret db-credentials
Saída esperada:
NAME TYPE DATA AGE
db-credentials Opaque 3 ...
Visualize o Secret como YAML. O Kubernetes armazena os valores em data como strings codificadas em base64, portanto, não espere ver a senha original nesta saída.
kubectl get secret db-credentials -o yaml
A saída esperada inclui:
data:
DB_NAME: b3JkZXJz
DB_PASSWORD: ...
DB_USER: b3JkZXJzLWFwcA==
type: Opaque
A codificação Base64 não é criptografia. Qualquer pessoa que possa ler o objeto Secret pode decodificar seus valores. Decodifique apenas o nome de usuário aqui para que você possa ver como a representação funciona sem exibir a senha.
kubectl get secret db-credentials -o 'jsonpath={.data.DB_USER}' | base64 --decode; echo
Saída esperada:
orders-app
Configurar um Pod a partir do Secret
Nesta etapa, você iniciará um Pod que lê o Secret como variáveis de ambiente.
O campo envFrom.secretRef importa todas as chaves de um Secret para o ambiente do container. Isso é semelhante ao padrão de ConfigMap do laboratório anterior, mas os valores vêm de um objeto Secret. O comando neste Pod imprime o nome de usuário e o nome do banco de dados, e então apenas confirma que uma senha foi carregada. Ele não imprime a senha em si.
Crie o arquivo secret-reader-pod.yaml:
cat > secret-reader-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: secret-reader
labels:
app: secret-reader
spec:
terminationGracePeriodSeconds: 0
containers:
- name: reader
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo user=${DB_USER}; echo database=${DB_NAME}; if [ -n "${DB_PASSWORD}" ]; then echo password-loaded; fi; sleep 3600'
envFrom:
- secretRef:
name: db-credentials
EOF
Aplique o manifesto do Pod:
kubectl apply -f secret-reader-pod.yaml
Saída esperada:
pod/secret-reader created
Aguarde até que o Pod esteja pronto (Ready):
kubectl wait --for=condition=Ready pod/secret-reader --timeout=120s
Saída esperada:
pod/secret-reader condition met
Leia os logs do Pod. A aplicação confirma que os valores do Secret estavam disponíveis, mas o valor da senha não é exibido.
kubectl logs secret-reader -c reader
Saída esperada:
user=orders-app
database=orders
password-loaded
Atualizar o Secret e Recriar o Pod
Nesta etapa, você atualizará o Secret e recriará o Pod para que o container receba os novos valores.
O ambiente de um container é capturado no momento em que ele inicia. Se um Secret é consumido como variáveis de ambiente, atualizar o objeto Secret não reescreve o ambiente dentro de um container que já está em execução. Inicie um novo Pod quando a aplicação precisar ler valores de Secret atualizados.
Aplique um patch no Secret com um novo usuário e senha de aplicação:
kubectl patch secret db-credentials --type merge --patch '{"stringData":{"DB_USER":"orders-worker","DB_PASSWORD":"rotated-password-456","DB_NAME":"orders"}}'
Saída esperada:
secret/db-credentials patched
Confirme o nome de usuário atualizado decodificando apenas DB_USER:
kubectl get secret db-credentials -o 'jsonpath={.data.DB_USER}' | base64 --decode; echo
Saída esperada:
orders-worker
Exclua o Pod antigo:
kubectl delete pod secret-reader
A saída esperada inclui:
pod "secret-reader" deleted
Recrie o Pod a partir do mesmo manifesto e aguarde até que ele esteja pronto:
kubectl apply -f secret-reader-pod.yaml
kubectl wait --for=condition=Ready pod/secret-reader --timeout=120s
Saída esperada:
pod/secret-reader created
pod/secret-reader condition met
Leia os logs novamente. O novo Pod agora vê o usuário atualizado a partir do Secret e continua evitando a impressão da senha bruta.
kubectl logs secret-reader -c reader
Saída esperada:
user=orders-worker
database=orders
password-loaded
Resumo
Você criou um Secret do Kubernetes, inspecionou seus dados codificados, decodificou uma chave não sensível para entender a representação, conectou o Secret a um Pod de aplicação e recriou o Pod após atualizar o Secret. Você também praticou um hábito importante para configurações sensíveis: verificar se a aplicação recebeu a senha sem imprimir o valor da senha nos logs.
