Secrets Management Basics

O que é um Kubernetes Secret?

Um Secret é um objeto da API do Kubernetes, muito semelhante a um ConfigMap, projetado especificamente para armazenar pequenas quantidades de dados sensíveis. A intenção é separar informações como senhas, tokens OAuth e chaves SSH do manifesto do seu Pod ou da imagem do contêiner.

Para começar, vamos entender por que os Secrets existem e como eles se comparam ao que você já conhece sobre ConfigMaps e até mesmo sobre o Docker.

A Fina Linha Entre Secret e ConfigMap

Tanto Secrets quanto ConfigMaps funcionam como armazenamentos de chave-valor. A principal diferença não está em como eles armazenam os dados inicialmente, mas em como o Kubernetes é projetado para tratá-los:

• Intenção: Um Secret sinaliza que os dados são confidenciais.
• Tratamento pelo Cluster: O Kubernetes evita exibir dados de Secret em logs ou na UI do Dashboard sem autorização explícita.
• Segurança Adicional: Um cluster pode ser configurado para criptografar os dados de Secret em repouso (no etcd), algo que geralmente não é feito para ConfigMaps.

A Realidade da Segurança: Codificação vs. Criptografia

Aqui está o ponto mais crítico que você precisa entender desde o início: por padrão, os dados em um Secret do Kubernetes são apenas codificados em Base64, não criptografados.

Base64 é um esquema de codificação para representar dados binários em formato de texto. Qualquer pessoa que possa ler o Secret pode facilmente decodificar seus dados. A segurança real dos Secrets não vem da ofuscação em Base64, mas do controle de acesso (RBAC) e de camadas adicionais de segurança que discutiremos mais adiante.

Criando Secrets

Assim como ConfigMaps, você pode criar Secrets de forma imperativa (kubectl) ou declarativa (YAML).

Método Declarativo (YAML)

Esta é a abordagem recomendada para infraestrutura como código (IaC). A estrutura do manifesto é muito parecida com a de um ConfigMap.

# db-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-app-secrets
type: Opaque # O tipo mais comum, para dados arbitrários
stringData:
  # Chaves e valores em texto plano. O Kubernetes irá codificá-los para Base64.
  ConnectionStrings__DefaultConnection: "Server=postgres-service;Database=mydotnetdb;User Id=appuser;Password=S3cr3tP@ssw0rd!"
  JwtSettings__Key: "uma-chave-secreta-muito-longa-e-segura-para-jwt"

Observe o campo stringData. Ele permite que você forneça os valores em texto plano, o que é muito mais conveniente. Quando você aplica este manifesto, o Kubernetes converte automaticamente esses valores para Base64 e os armazena no campo data.

Para criar o Secret:
kubectl apply -f db-secret.yaml

Para inspecioná-lo e ver a versão codificada em Base64:
kubectl get secret my-app-secrets -o yaml

Você verá um campo data com valores que parecem aleatórios. Você pode decodificá-los manualmente:
echo 'U2VydmVyPW...' | base64 --decode

Consumindo Secrets em Pods

A mecânica de consumo de Secrets é idêntica à de ConfigMaps. Seus contêineres .NET podem acessá-los de duas maneiras principais.

Método 1: Como Variáveis de Ambiente

Esta é uma abordagem muito comum para injetar configurações como connection strings ou chaves de API, que sua aplicação .NET pode ler facilmente através do IConfiguration.

Dado seu background em .NET, o exemplo a seguir será muito familiar. Ele mostra como injetar todos os pares chave-valor do nosso Secret como variáveis de ambiente no contêiner da sua API.

No Program.cs de sua aplicação ASP.NET Core, o provedor de configuração de variáveis de ambiente mapeia automaticamente as chaves. Por exemplo, a variável de ambiente ConnectionStrings__DefaultConnection (com dois underscores) é corretamente interpretada como a seção ConnectionStrings e a chave DefaultConnection no appsettings.json.

Lembre-se do ponto crucial da lição anterior: variáveis de ambiente são imutáveis. Se você atualizar o Secret, os Pods em execução não verão a mudança. Você precisaria reiniciá-los.

Método 2: Como Arquivos em um Volume

Este método é ideal para dados que são inerentemente arquivos, como certificados TLS (.crt, .key) ou um arquivo google-credentials.json. Cada chave no Secret se torna um arquivo no diretório montado.

A sintaxe no manifesto do Deployment é a mesma que você viu para ConfigMaps:

spec:
  containers:
  - name: my-dotnet-api
    image: my-registry/my-dotnet-api:v1.0
    volumeMounts:
    - name: tls-certs-volume
      mountPath: "/etc/ssl/certs"
      readOnly: true
  
  volumes:
  - name: tls-certs-volume
    secret:
      secretName: my-tls-secret # Nome do Secret contendo os arquivos .crt e .key

A grande vantagem aqui, como vimos com ConfigMaps, é que os arquivos montados a partir de um Secret são atualizados dinamicamente. Se o Secret for atualizado, o Kubernetes propagará a mudança para os arquivos dentro dos Pods em execução após um curto período, sem a necessidade de um reinício.

Estratégias de Segurança para Secrets

Como vimos, o Base64 não oferece segurança real. A proteção dos seus Secrets depende de outras camadas.

Resumindo as estratégias de segurança para Secrets:

1. Controle de Acesso Baseado em Função (RBAC): Esta é a sua primeira e mais importante linha de defesa. Use as políticas do RBAC para garantir que apenas os ServiceAccounts dos Pods que realmente precisam de um Secret tenham permissão para lê-lo. Siga o princípio do menor privilégio.
2. Criptografia em Repouso (Encryption at Rest): Configure seu cluster Kubernetes (ou use um serviço gerenciado como EKS, AKS ou GKE que já o faça) para criptografar o conteúdo do etcd, o banco de dados do cluster. Isso protege seus Secrets caso alguém ganhe acesso direto ao armazenamento do etcd.
3. Gerenciadores de Segredos Externos: Para a máxima segurança e conformidade, as organizações usam ferramentas externas como HashiCorp Vault ou os gerenciadores de segredos nativos da nuvem (AWS Secrets Manager, Azure Key Vault, Google Secret Manager). Operadores do Kubernetes, como o External Secrets Operator, podem sincronizar esses segredos externos de forma segura para dentro do seu cluster.

Conclusão

Parabéns! Você agora entende como gerenciar dados sensíveis no Kubernetes. Esta é uma habilidade fundamental para qualquer desenvolvedor que trabalha com aplicações em contêineres.

Principais Pontos:

• Secrets são para dados sensíveis: Use-os para senhas, tokens e chaves, em vez de ConfigMaps.
• Base64 NÃO é criptografia: É apenas uma codificação. Qualquer pessoa com acesso pode decodificá-lo.
• Dois métodos de consumo: Injeção como variáveis de ambiente (estático, requer reinício do Pod para atualizar) ou montagem como volumes (dinâmico, atualiza automaticamente).
• A segurança real vem em camadas: A base é o RBAC, fortalecida pela criptografia em repouso e, para necessidades avançadas, por gerenciadores de segredos externos.

Próxima Lição:
Agora que sabemos como gerenciar tanto a configuração (ConfigMaps) quanto os segredos (Secrets), estamos prontos para começar a pensar em implantações no mundo real. A próxima lição, "Deploying .NET Aspire Applications to the Cloud", começará a juntar essas peças, preparando nossa imagem de aplicação para ser implantada em serviços como Render e Amazon ECR, onde o gerenciamento de segredos é uma realidade diária.