> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mka1.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Artefatos assinados e cadeia de suprimentos

> Como o MKA1 garante a integridade de imagens de contêiner por meio de marcação imutável de artefatos, pipelines CI/CD controlados e uso obrigatório de registros privados.

O MKA1 impõe uma cadeia de suprimentos determinística, onde toda imagem de contêiner é rastreável até um commit específico da origem, construída exclusivamente por pipelines CI automatizados e armazenada em registros privados que rejeitam artefatos externos.

## O que está ativo

### Marcação imutável de artefatos

Cada imagem de contêiner construída pela plataforma é marcada com o SHA do commit de origem do git. Isso cria um vínculo imutável e único entre o código-fonte e o binário implantado:

* As imagens são enviadas para o Amazon ECR com tags de commit-SHA (por exemplo, `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 impõem uma janela de retenção de 30 dias para imagens de commit-SHA, mantendo apenas a tag `latest` indefinidamente.

### Pipeline CI/CD controlado

Todas as imagens de contêiner se originam de workflows do GitHub Actions -- não são permitidos envios manuais de imagens:

* Os workflows de implantação autenticam com a AWS via federação OIDC (sem credenciais de longa duração).
* O GitHub Actions utiliza versões fixas de actions para builds reproduzí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 (por exemplo, `go mod verify` para módulos Go).
* O acesso a módulos privados é controlado via PATs do GitHub com escopo restrito, em vez de credenciais amplas.

### Obrigatoriedade de registro privado

As implantações no Kubernetes puxam imagens exclusivamente dos nossos registros privados Amazon ECR:

* Todos os manifestos de serviços referenciam URIs de imagens 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 varredura nativa de vulnerabilidades do ECR está habilitada, fornecendo avaliação automatizada do conteúdo das imagens.

### Gerenciamento de segredos e 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 puro no repositório ou em 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 ao vivo do cluster.

**Rastreabilidade do código-fonte à imagem:** Cada tag de imagem implantada mapeia para um commit SHA do git. Dado qualquer contêiner em execução, podemos identificar a revisão exata do código-fonte:

```bash theme={null}
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
```

**Verificação da origem do registro:** Confirmamos que todas as cargas de trabalho em execução puxam exclusivamente do nosso ECR privado:

```bash theme={null}
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
```

**Auditoria do pipeline CI:** As execuções de workflow do GitHub Actions são registradas e auditáveis, fornecendo um histórico completo de quem disparou cada build e qual commit produziu cada imagem.

## Evidências

### Imagem ECR com tag de commit-SHA

```text theme={null}
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 puxando do ECR privado

```text theme={null}
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 impondo builds apenas via CI

```yaml theme={null}
# 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 }}
```