Saltar para o conteúdo principal
A MKA1 impõe uma cadeia de suprimentos determinística onde cada imagem de contêiner é rastreável a um commit de código-fonte específico, construída exclusivamente por pipelines de CI automatizados e armazenada em registros privados que rejeitam artefatos externos.

​
O que está ativo

​
Etiquetagem imutável de artefatos

Cada imagem de contêiner construída pela plataforma é etiquetada com o SHA do commit de origem. Isso cria um vínculo imutável e biunívoco entre o código-fonte e o binário implantado:
  • As imagens são enviadas ao Amazon ECR com tags de commit-SHA (ex.: sha-a1b2c3d), garantindo que cada artefato seja identificável de forma única.
  • Os repositórios ECR são configurados como registros privados restritos à conta AWS da organização.
  • Políticas de ciclo de vida do ECR aplicam uma janela de retenção de 30 dias para imagens com tag de commit-SHA, mantendo apenas a tag latest indefinidamente.

​
Pipeline de CI/CD controlado

Todas as imagens de contêiner se originam de workflows do GitHub Actions — nenhum push manual de imagem é permitido:
  • Os workflows de implantação autenticam com a AWS via federação OIDC (sem credenciais de longa duração).
  • As GitHub Actions utilizam versões fixas de actions para builds reprodutíveis e determinísticos.
  • O Docker Buildx produz imagens multiplataforma a partir de um ambiente de build consistente.
  • A integridade das dependências é verificada durante os builds (ex.: go mod verify para módulos Go).
  • O acesso a módulos privados é controlado por PATs do GitHub com escopo restrito, em vez de credenciais amplas.

​
Aplicação de registro privado

As implantações do Kubernetes baixam imagens exclusivamente dos nossos registros privados do Amazon ECR:
  • Todos os manifests de serviço referenciam URIs de imagem ECR totalmente qualificadas dentro da conta AWS da organização.
  • Nenhum registro público ou de terceiros é referenciado em cargas de trabalho de produção.
  • A verificação nativa de vulnerabilidades do ECR está habilitada, fornecendo avaliação automatizada do conteúdo das imagens.

​
Segredos e gerenciamento de chaves

  • Todos os segredos são criptografados em repouso usando SOPS com uma chave AWS KMS gerenciada pelo cliente.
  • Segredos nunca são armazenados em texto claro no repositório ou nos logs de CI.
  • O acesso ao cluster Kubernetes é governado por RBAC integrado ao IAM, restringindo quem pode interagir com cargas de trabalho e registros.

​
Como validamos

Validamos a cadeia de suprimentos por meio de revisão de infraestrutura como código e inspeção do cluster ao vivo. Rastreabilidade de origem até imagem: Cada tag de imagem implantada corresponde a um SHA de commit do git. A partir de qualquer contêiner em execução, podemos identificar a revisão exata do código-fonte: 
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
Verificação de origem do registro: Confirmamos que todas as cargas de trabalho em execução baixam imagens exclusivamente do nosso ECR privado: 
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
Auditoria do pipeline de CI: As execuções de workflows do GitHub Actions são registradas e auditáveis, fornecendo um histórico completo de quem acionou cada build e qual commit produziu cada imagem.

​
Evidências

​
Imagem ECR com tag de commit-SHA

REPOSITORY                          TAG              DIGEST
[redacted-account].dkr.ecr.us-west-2...   sha-a1b2c3d      sha256:[redacted]
[redacted-account].dkr.ecr.us-west-2...   latest           sha256:[redacted]

​
Pods do Kubernetes baixando do ECR privado

mkllm-gateway-...     [redacted-account].dkr.ecr.us-west-2.amazonaws.com/mkllm-gateway:sha-[redacted]
mkllm-worker-...      [redacted-account].dkr.ecr.us-west-2.amazonaws.com/mkllm-worker:sha-[redacted]
mk1-api-...           [redacted-account].dkr.ecr.us-west-2.amazonaws.com/mk1-api:sha-[redacted]
kong-...               [redacted-account].dkr.ecr.us-west-2.amazonaws.com/kong:sha-[redacted]

​
Workflow do GitHub Actions aplicando builds exclusivos via CI

# Trecho de deploy-mk1.yaml
on:
  push:
    branches: [main]
    paths: ["mk1/**"]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
      - uses: aws-actions/amazon-ecr-login@v2
      - run: skaffold run -p ${{ matrix.environment }}