Aula 19 - Gestão Segura de Segredos e Certificados em CI/CD 🔑

📑 1. Fundamentos Teóricos & Análise Técnica

Um dos vetores de ataque mais recorrentes contra a cadeia de suprimentos de software é o vazamento de chaves de API estáticas e credenciais de nuvem gravadas em variáveis de ambiente de CI/CD.

A segurança moderna de infraestrutura aboliu credenciais persistentes em favor de Identidades Criptográficas Efêmeras: 1. O Problema das Long-Lived Credentials: - Chaves de acesso AWS IAM ou Service Account Keys do GCP armazenadas como segredos de repositório têm prazo indeterminado. Se um pipeline for comprometido ou um log vazar a variável, o atacante adquire persistência silenciosa. 2. OpenID Connect (OIDC) Federado e Zero-Secret CI/CD: - O runner de CI (ex: GitHub Actions) atua como um provedor de identidade (IdP) emitindo um token JWT assinado criptograficamente contendo claims verificáveis (repositório, branch, commit SHA). - O provedor de nuvem (AWS, Azure, GCP ou HashiCorp Vault) valida a assinatura do token OIDC diretamente com o IdP e concede credenciais temporárias de curto prazo (válidas por 15 a 60 minutos) com permissões restritas. 3. HashiCorp Vault e Segredos Dinâmicos: - Em vez de compartilhar uma senha fixa de banco de dados entre dezenas de microsserviços, a aplicação autentica-se no Vault, que provisiona na hora um usuário único no banco de dados com Time-to-Live (TTL) limitado, revogando o acesso automaticamente ao expirar o tempo.

📐 Arquitetura Conceitual & Diagrama de Fluxo

sequenceDiagram
    autonumber
    participant Runner as GitHub Actions Runner
    participant IdP as GitHub OIDC Provider
    participant AWS as AWS STS (AssumeRoleWithWebIdentity)
    participant Cloud as Recursos Cloud (S3, EKS, RDS)
    Runner->>IdP: Solicita OIDC Token JWT
    IdP-->>Runner: JWT Assinado (Audience, Repository, Ref)
    Runner->>AWS: Envia JWT e solicita AssumeRole
    AWS->>IdP: Valida chave pública e claims da organização
    AWS-->>Runner: Credenciais Temporárias STS (Válidas por 15min)
    Runner->>Cloud: Executa deploy com segurança zero-secret!
    Note over Runner,Cloud: Credenciais expiram automaticamente; zero segredo estático mantido!

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Eliminação de Segredos Estáticos: Nenhuma credencial permanente de nuvem reside armazenada em configurações de CI/CD. - Claims-Based Access Control: Políticas IAM que concedem permissão de deploy apenas se o commit pertencer à branch main da organização oficial. - Auditoria Centralizada de Acessos: Cada requisição gera logs unificados rastreando a autoria exata do job de pipeline até o commit. - Time-To-Live (TTL) Curto: Janela de exposição reduzida para minutos em caso improvável de interceptação de token.

🛠️ 2. Implementação Prática em Gestão de Segredos, HashiCorp Vault e OIDC

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// oidc_cloud_deploy.yml (Pipeline GitHub Actions sem Segredos com AWS OIDC)
name: Cloud Deploy via OIDC

on:
  push:
    branches: [main]

permissions:
  id-token: write # Permissão obrigatória para requisitar o token JWT OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Autenticação Segura via OIDC (Zero Chaves Estáticas!)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsWorkloadDeployRole
          aws-region: us-east-1
          audience: https://github.com/organizacao-oficial

      - name: Deploy em Infraestrutura Protegida
        run: |
          echo "Executando sincronização segura com credenciais temporárias do STS:"
          aws sts get-caller-identity
          aws s3 sync ./dist s3://portal-producao-bucket --delete

💡 Análise Passo a Passo do Código

1. Diretiva id-token: write: Autoriza o runner a solicitar tokens OIDC federados de curto prazo ao servidor do GitHub.
2. Role-to-Assume Declarativa: Associa o job a uma IAM Role previamente configurada para confiar apenas no repositório corporativo específico.
3. Zero Segredos em Settings: Elimina a necessidade de manter AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY no painel de configurações.

🎯 3. Próximos Passos & Sequência Didática