Skip to main content
MKA1 enforces a deterministic supply chain where every container image is traceable to a specific source commit, built exclusively through automated CI pipelines, and stored in private registries that reject external artifacts.

​
What is active

​
Immutable artifact tagging

Every container image built by the platform is tagged with the originating git commit SHA. This creates an immutable, one-to-one link between source code and the deployed binary:
  • Images are pushed to Amazon ECR with commit-SHA tags (e.g., sha-a1b2c3d), ensuring each artifact is uniquely identifiable.
  • ECR repositories are configured as private registries scoped to the organization’s AWS account.
  • ECR lifecycle policies enforce a 30-day retention window for commit-SHA images, keeping only the latest tag indefinitely.

​
Controlled CI/CD pipeline

All container images originate from GitHub Actions workflows — no manual image pushes are permitted:
  • Deployment workflows authenticate with AWS via OIDC federation (no long-lived credentials).
  • GitHub Actions use pinned action versions for reproducible, deterministic builds.
  • Docker Buildx produces multi-platform images from a consistent build environment.
  • Dependency integrity is verified during builds (e.g., go mod verify for Go modules).
  • Private module access is controlled via scoped GitHub PATs rather than broad credentials.

​
Private registry enforcement

Kubernetes deployments pull images exclusively from our private Amazon ECR registries:
  • All service manifests reference fully-qualified ECR image URIs within the organization’s AWS account.
  • No public or third-party registries are referenced in production workloads.
  • ECR native vulnerability scanning is enabled, providing automated assessment of image contents.

​
Secrets and key management

  • All secrets are encrypted at rest using SOPS with a customer-managed AWS KMS key.
  • Secrets are never stored in plaintext in the repository or in CI logs.
  • Kubernetes cluster access is governed by IAM-integrated RBAC, restricting who can interact with workloads and registries.

​
How we validate it

We validate the supply chain through infrastructure-as-code review and live cluster inspection. Source-to-image traceability: Every deployed image tag maps to a git commit SHA. Given any running container, we can identify the exact source revision: 
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
Registry origin verification: We confirm that all running workloads pull exclusively from our private ECR: 
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
CI pipeline audit: GitHub Actions workflow runs are logged and auditable, providing a full history of who triggered each build and which commit produced each image.

​
Evidence

​
ECR image with commit-SHA tag

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

​
Kubernetes pods pulling from private ECR

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]

​
GitHub Actions workflow enforcing CI-only builds

# Excerpt from 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 }}