Configurações seguras com Secrets

Tiago Temporin

2 anos atrás

Dando continuidade a nossa série de posts sobre Kubernetes, assim como dito no post sobre ConfigMap, nesse post vamos falar um pouco sobre como mandar uma configuração segura utilizando o recurso Secrets.

Esse recurso, como você já deve estar pensando, é utilizado para guardar dados sensíveis, como senhas, tokens de acesso ou chaves de API que sua aplicação precisa para funcionar, mas que não devem ser armazenadas diretamente no código, no manifesto do Deployment ou em ConfigMap.

Criando uma Secret

Assim como o recurso ConfigMap, Secrets são bem simples de serem criados, já que basicamente só precisamos nos preocupar com o atributo data.

apiVersion: v1
kind: Secret
metadata:
  name: database-credentials
type: Opaque
data:
  USERNAME: c3VfcGFzc3dvcmQ=
  PASSWORD: c3VfcGFzc3N3b3JkIA==

Neste manifesto, definimos:

apiVersion: Versão da API utilizada (v1 é padrão)
kind: Tipo de recurso
metadata: Informações sobre a Secret, incluindo seu nome, namespace, labels e etc
type: O tipo de Secret
data: Uma lista de pares chave-valor onde os valores estão codificados em Base64

Você pode salvar este manifesto em um arquivo YAML (ex: database-credentials.yaml) e então aplicar usando:

kubectl apply -f database-credentials.yaml

Outra forma de criar uma secret seria utilizando o comando kubectl create secret.

kubectl create secret generic database-credentials \\
  --from-literal=USERNAME=seu_usuario \\
  --from-literal=PASSWORD=sua_senha_segura

Lembre-se de, por motivos de segurança, nunca inclua dados sensíveis diretamente no manifesto ou em ConfigMaps. Sempre criptografe ou codifique seus dados antes de armazená-los.

Tipos de segredos no Kubernetes

O Kubernetes oferece suporte a diferentes tipos de Secrets, cada um com suas próprias características e casos de uso:

Tipo de Secreto	“Type” no manifesto	Descrição
Opaco	“Opaque”	Armazena dados arbitrários codificados em Base64. Ideal para senhas, tokens de acesso e chaves secretas.
Docker registry	“kubernetes.io/dockercfg“	Armazena credenciais para acessar registros Docker privados.
TLS	“kubernetes.io/tls“	Armazena certificados e chaves privadas para estabelecer conexões TLS seguras.
Serviço de conta	“kubernetes.io/service-account-token“	Armazena o token de autenticação associado a um serviço de conta do Kubernetes.
Bootstrapping	“bootstrap.kubernetes.io/token“	Usado durante o processo de bootstrapping do nó para assinar ConfigMaps conhecidos.

NOTA: como o Kubernetes é uma ferramenta em constante evolução, é extremamente importante ficar de olho na sua documentação oficial. Isso por que, com o tempo, além de alguns tipos poderem ser depreciados, novos podem ser adicionados.

Exemplo de uso com Deployment

Vamos simular um cenário onde nossa aplicação precisa se conectar a um banco de dados usando uma senha armazenada com segurança.

Para utilizar os dados da secret que criamos anteriormente, precisamos configurar um deployment como o exemplo abaixo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-aplicacao
spec:
  template:
    spec:
      containers:
      - name: app
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: database-credentials
              key: USERNAME
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: database-credentials
              key: PASSWORD

No deployment, referenciamos a Secret usando valueFrom e secretKeyRef. Nos atributos name e key configuramos, respectivamente, o nome da Secret, seguido pela chave que definimos no manifesto da Secret.

Um detalhe importante aqui é que, o nome da variável de ambiente não precisa ser igual a chave que criamos na Secret.

Boas Práticas

Para manter os dados das Secrets ainda mais seguros, embora não seja obrigatório, é importante seguir as boas práticas:

Não armazene Secrets em repositórios de código: Utilize ferramentas de gerenciamento de Secrets ou armazene-os fora do código.
Use RBAC para controlar o acesso aos Secrets: Defina políticas de acesso para limitar quem pode criar, acessar ou modificar Secrets.
Secrets por ambientes: Use diferentes valores de Secrets para diferentes ambientes (dev, test, produção)
Rotacione Secrets regularmente: Automatize a troca de Secrets para reduzir riscos de segurança.

Conclusão

O recurso Secret é uma peça fundamental para garantir a segurança e confidencialidade das suas aplicações no Kubernetes. Ao utilizar os tipos corretos e seguir as melhores práticas, você pode proteger suas informações sensíveis e manter sua infraestrutura segura.

No próximo post, vou mostrar como armazenar os valores das secrets em um cofre fora do ambiente Kubernetes.

Para ser notificado assim que o post sair, se inscreva na nossa newsletter. Além ficar atualizado, você ainda ganha 20% de desconto em qualquer treinamento, incluindo o curso de Containers & Kubernetes.

Até a próxima!