If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/GoogleContainerTools/kaniko shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 11mo ago
• 16 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 11mo ago
• ⚠ Concentrated ownership — top contributor handles 72% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live GoogleContainerTools/kaniko repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GoogleContainerTools/kaniko.

What it runs against: a local clone of GoogleContainerTools/kaniko — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in GoogleContainerTools/kaniko | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 370 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of GoogleContainerTools/kaniko. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/GoogleContainerTools/kaniko.git
#   cd kaniko
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of GoogleContainerTools/kaniko and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GoogleContainerTools/kaniko(\\.git)?\\b" \\
  && ok "origin remote is GoogleContainerTools/kaniko" \\
  || miss "origin remote is not GoogleContainerTools/kaniko (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "cmd/executor/main.go" \\
  && ok "cmd/executor/main.go" \\
  || miss "missing critical file: cmd/executor/main.go"
test -f "cmd/executor/cmd/root.go" \\
  && ok "cmd/executor/cmd/root.go" \\
  || miss "missing critical file: cmd/executor/cmd/root.go"
test -f "go.mod" \\
  && ok "go.mod" \\
  || miss "missing critical file: go.mod"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "deploy/Dockerfile" \\
  && ok "deploy/Dockerfile" \\
  || miss "missing critical file: deploy/Dockerfile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 370 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~340d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/GoogleContainerTools/kaniko"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Kaniko is a tool that builds Docker container images from Dockerfiles entirely in userspace without requiring a Docker daemon, enabling secure container image builds inside Kubernetes clusters and other restricted environments. It executes each Dockerfile instruction in a sandbox without privileged access, making it ideal for CI/CD pipelines where running Docker-in-Docker is impractical or dangerous. Monorepo structure: cmd/executor/ contains the main kaniko executor binary entry point (main.go, root.go), cmd/warmer/ provides image warming tools, Go packages handle Dockerfile parsing and layer building. GitHub Actions workflows in .github/workflows/ define CI (unit-tests.yaml, integration-tests.yaml, nightly-vulnerability-scan.yml). Examples in examples/ show Kubernetes Pod YAML configs (kaniko-test.yaml, pod.yaml) for running kaniko as a container.

DevOps engineers and platform teams running CI/CD pipelines in Kubernetes who need to build container images without Docker socket access, particularly in air-gapped or security-hardened clusters. Also used by developers building container images in local Kubernetes environments or cloud-native CI systems like Google Cloud Build.

⚠️ ARCHIVED AND NO LONGER MAINTAINED as of the README timestamp. The project has comprehensive test coverage (unit-tests.yaml, integration-tests.yaml workflows), CI/CD pipelines, and Go 1.24 support, but is explicitly marked as no longer developed or supported by Google. Code remains available for historic purposes only.

CRITICAL: This repository is archived and unmaintained. No future security patches, dependency updates, or bug fixes will be released. The dependency tree includes end-of-life or slowmove packages (moby/buildkit v0.22.0, older Azure SDK versions). Using this in production violates your SLA expectations—migrate to active alternatives like Buildkit, Podman, or containerd image build tooling.

Nothing—project is archived. Last activity reflects historic development: unit tests, integration tests, nightly vulnerability scans, and image builds via GitHub Actions. No active PRs or milestones. The .github/dependabot.yml suggests automated dependency monitoring was configured but is now inactive.

git clone https://github.com/GoogleContainerTools/kaniko.git
cd kaniko
make help  # Check Makefile for available targets
go test ./...  # Run unit tests

Note: This is historical reference only; do not deploy to production.

Daily commands:

make build  # Build the executor binary
make test   # Run all tests
./out/executor --dockerfile=Dockerfile --destination=myrepo/myimage:tag  # Manual execution

Kubernetes usage: Deploy as a Pod using manifests in examples/pod.yaml or examples/kaniko-test.yaml.

• cmd/executor/main.go — Entry point for the kaniko executor; initializes container build pipeline and orchestrates all build stages
• cmd/executor/cmd/root.go — Core CLI command definition and build orchestration logic; every contributor must understand the build flow here
• go.mod — Dependency management (Go 1.24.0); critical for understanding cloud storage, container registry, and Git integration
• README.md — Project archived status and core purpose (build container images in Kubernetes); context for all development
• deploy/Dockerfile — Build definition for kaniko executor image itself; demonstrates the build patterns kaniko implements
• examples/pod.yaml — Canonical Kubernetes Pod example showing kaniko executor configuration; reference for integration testing and deployment
• DEVELOPMENT.md — Build and development setup instructions; essential onboarding for local development and testing

Add a new cloud storage backend (e.g., MinIO, GCS variant)

1. Review existing cloud storage implementations in go.mod dependencies (cloud.google.com/go/storage, AWS SDK, Azure SDK) (go.mod)
2. Add new dependency to go.mod for your storage provider (go.mod)
3. Create storage client initialization in executor startup (likely cmd/executor/cmd/root.go) (cmd/executor/cmd/root.go)
4. Add integration test to validate storage connectivity and artifact upload (integration/config.go)

Add a new Dockerfile instruction optimization

1. Review current build flow and layer caching logic in executor root command (cmd/executor/cmd/root.go)
2. Implement instruction handler (if not already present in containerregistry library) (cmd/executor/cmd/root.go)
3. Add integration test case with sample Dockerfile (integration/dockerfiles-with-context)
4. Run integration test to validate optimization (integration-test.sh)

Add a new Kubernetes deployment example

1. Study canonical Pod example for kaniko configuration patterns (examples/pod.yaml)
2. Create new YAML manifest in examples directory with your scenario (examples/pod-new-scenario.yaml)
3. Document the example in DEVELOPMENT.md or tutorial (DEVELOPMENT.md)
4. Add deployment test or reference to examples in CI workflow if needed (.github/workflows/integration-tests.yaml)

Add a new cache warmer feature

1. Review cache warmer structure and command initialization (cmd/warmer/cmd/root.go)
2. Extend root.go with new cache warming logic (cmd/warmer/cmd/root.go)
3. Create or update example Pod configuration for the new warmer feature (examples/kaniko-warmer.yaml)
4. Add integration test to validate warmer functionality (integration/config.go)

• Go 1.24.0 with go-containerregistry — Lightweight, statically-linked binary suitable for unprivileged container execution; google-containerregistry provides OCI standards compliance without Docker daemon
• Multi-cloud storage (GCS, S3, Azure Blob Storage) — Enables kaniko deployment across cloud providers and hybrid environments; avoids vendor lock-in for build artifact caching
• Kubernetes native execution (Pod-based) — Leverages Kubernetes RBAC, ServiceAccounts, and resource limits; eliminates Docker-in-Docker overhead and privilege escalation risks
• Credential helpers (ECR, ACR, Docker) — Integrates with native cloud IAM (AWS STS, Azure AD) and Docker credential chains; reduces secrets management complexity

• Daemon-less container build (no Docker socket)

  • Why: Improves security posture and reduces privilege requirements in Kubernetes
  • Consequence: Cannot use Docker daemon features (socket forwarding, networking plugins); some Dockerfile instructions may have limited functionality

• Layer caching relies on registry or cloud storage, not local disk

  • Why: Enables fast horizontal scaling and multi-node builds
  • Consequence: Requires reliable network and cloud storage access; initial cache population slower than local Docker

• Single-pass Dockerfile execution (no interactive terminal)

  • Why: Simplifies build semantics and improves performance
  • Consequence: Debugging build failures requires logs and artifact inspection, not real-time shell access

• Archived repository (no longer maintained)

  • Why: Project shift from Google or resource constraints
  • Consequence: Security updates and new Dockerfile features will not be backported; users must fork or migrate to active alternatives

• Interactive debugging or shell access during build
• Docker daemon compatibility or socket proxying
• Privileged execution or system-level container features
• Windows container support (Linux-focused)
• Non-Kubernetes execution environments (though design is generally container-agnostic)
• Real-time build streaming to non-Kubernetes clients

Archived status: This is a historical snapshot—do not assume it will build or function against modern container registries, Kubernetes, or dependencies. Docker socket expectation: Despite userspace operation, some features may still expect Docker environment variables or credential helpers (gcr, ECR, ACR). Multi-architecture builds: Examples and CI reference multi-arch images (docs/images/multi-arch.drawio.svg), but support may be incomplete or outdated. Dependency mismatches: go.mod pins moby/buildkit v0.22.0 and other packages that may have unpatched CVEs; running go mod tidy against modern Go may break the build. No active support: MAINTAINERS file exists but contributions are not accepted per the archived notice.

• Userspace filesystem layering — Kaniko's core innovation—building layers without kernel mounts or daemon privileges requires understanding overlayfs simulation, file state tracking, and deterministic snapshots
• Container image OCI spec and layer format — Kaniko must produce valid OCI-compliant images (tarball layers, config JSON, manifest) without Docker daemon; knowing layer compression, digests, and config encoding is critical
• Dockerfile instruction execution context — Kaniko executes each Dockerfile RUN, COPY, ADD, etc. in isolated userspace contexts—requires understanding file path resolution, environment variable scoping, and working directory state
• Container registry authentication and credential helpers — Kaniko supports ECR credential helper, GCR helper, Azure ACR, and Docker credential stores; understanding how it resolves and applies credentials to registries is essential for multi-cloud pipelines
• Kubernetes Pod-as-build-executor pattern — Kaniko runs as a container inside a Kubernetes Pod, not as a cluster controller—understanding ephemeral workload patterns, volume mounts for build contexts, and Pod resource quotas is foundational
• Multi-stage Docker builds and layer caching — Kaniko's performance depends on layer cache optimization and handling of FROM statements across stages; understanding BuildKit's snapshot model and cache invalidation is important
• Go module dependency management and vendor workflows — The project is Go-heavy (708KB Go code) with 60+ dependencies; understanding go.mod resolution, indirect dependency resolution, and vendor/ directory patterns is needed for maintenance

• moby/moby — Docker Engine reference implementation; kaniko depends on moby/buildkit and Docker libraries from here
• moby/buildkit — Active successor to kaniko's approach—modern, maintained alternative for building container images without Docker daemon
• containers/podman — Daemonless container engine with native rootless build support, a contemporary replacement for kaniko in Kubernetes environments
• GoogleContainerTools/distroless — Companion Google project providing minimal base images optimized for kaniko and other container build tools
• kubernetes/kubernetes — Kaniko is designed specifically to run as a Kubernetes workload; understanding Pod specs, ImagePullSecrets, and kubelet image handling is essential

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for Azure Blob Storage backend

The repo has Azure SDK dependencies (github.com/Azure/azure-sdk-for-go/sdk/storage/azblob) and examples (examples/pod-blobstorage.yaml), but the integration test workflow (.github/workflows/integration-tests.yaml) likely only covers GCS and S3. Azure blob storage backend needs dedicated integration tests to ensure parity with other cloud storage backends.

• [ ] Review .github/workflows/integration-tests.yaml to confirm Azure tests are missing
• [ ] Create Azure storage integration test cases in the test suite
• [ ] Add Azure credentials/setup to the CI workflow (similar to existing GCS/S3 setup)
• [ ] Document Azure test prerequisites in DEVELOPMENT.md

Add unit tests for cmd/warmer/cmd/root.go

The warmer command (cmd/warmer) appears to be a significant feature with its own Kubernetes example (examples/kaniko-warmer.yaml), but cmd/warmer/cmd/root.go has no corresponding test file. The executor command has root_test.go (cmd/executor/cmd/root_test.go), establishing a pattern that should be followed.

• [ ] Create cmd/warmer/cmd/root_test.go following the pattern of cmd/executor/cmd/root_test.go
• [ ] Add tests for warmer initialization, flag parsing, and error handling
• [ ] Run go test ./cmd/warmer/cmd to verify coverage
• [ ] Update test count in README or CI badge if applicable

Document design decisions in docs/designdoc.md for snapshot/layer caching strategy

The repo has design proposal templates (docs/design_proposals/design-proposal-template.md) and existing proposals (filesystem-resolution-proposal-01.md), but docs/designdoc.md appears to be a stub. Given that layer caching is critical to kaniko's performance and the dependencies include moby/buildkit and minio/highwayhash (hashing for caching), the main design document should detail the snapshot and cache layer implementation strategy.

• [ ] Review pkg/ directory structure to understand snapshot and cache implementations
• [ ] Expand docs/designdoc.md with sections on: layer snapshot strategy, cache invalidation, hash computation (minio/highwayhash usage)
• [ ] Document how kaniko differs from standard Docker layer caching
• [ ] Add architecture diagrams similar to docs/images/multi-arch.drawio.svg structure

• Add Go unit tests for cmd/warmer/cmd/root.go (currently only cmd/executor has root_test.go)—use testify or standard table-driven patterns to cover image warming scenarios.
• Document the exact Kubernetes RBAC permissions required for kaniko Pods in examples/ (create a new examples/kaniko-rbac.yaml with ServiceAccount, Role, and RoleBinding manifests)—no explicit examples exist despite Pod configs referencing serviceAccountName.
• Add missing integration test coverage for Azure Blob Storage and AWS S3 build contexts (integration-tests.yaml exists but specific cloud storage test cases are not visible in the file list)—follow existing test patterns in .github/workflows/integration-tests.yaml.

• High · Archived Project - No Active Maintenance — README.md. The project is archived and no longer developed or maintained according to the README. This means security vulnerabilities will not receive fixes, patches, or updates. Active projects are crucial for security compliance. Fix: Consider using actively maintained alternatives or fork and maintain the project internally if critical for operations. Do not rely on this in production without careful security review and in-house maintenance.
• High · Outdated Go Version — go.mod. The project specifies 'go 1.24.0' which appears to be a future or non-existent version. This could indicate misconfiguration or unrealistic version specifications, potentially causing build inconsistencies and security issues. Fix: Use a stable, well-tested Go version (e.g., 1.21.x or 1.22.x). Verify the intended version and update go.mod accordingly.
• High · Incompatible Docker SDK — go.mod. The dependency 'github.com/docker/docker v28.1.1+incompatible' is marked as incompatible. Incompatible packages may have unresolved API changes or security issues and could cause runtime failures. Fix: Update to a compatible version of docker/docker. Test thoroughly after upgrading to ensure stability and security.
• Medium · Multiple Deprecated/Unmaintained Dependencies — go.mod. Several dependencies appear outdated or may lack active maintenance: github.com/google/go-github (v17.0.0+incompatible - very old), github.com/pkg/errors (deprecated in favor of standard error handling), github.com/Azure/go-autorest (superseded by azure-sdk-go). These can harbor unpatched vulnerabilities. Fix: Audit and update deprecated dependencies. Replace github.com/pkg/errors with Go 1.13+ error wrapping. Use modern Azure SDK packages where applicable.
• Medium · Public Cosign Key in Repository — cosign.pub. The file 'cosign.pub' is stored in the repository root. While public keys are not secrets, storing them in the repo alongside code can indicate weak key management practices and makes it harder to rotate keys. Fix: Store cosign public keys in a dedicated, secure location (e.g., artifact repositories or key management services). Document key rotation procedures.
• Medium · Incomplete Dependency Listing — go.mod. The go.mod content appears truncated at the indirect dependencies section ('github.com/Azure/go-autorest/aut'). This incomplete dependency information makes it impossible to perform a complete security audit of all transitive dependencies. Fix: Provide complete go.mod and go.sum files for full dependency analysis. Run 'go mod verify' to ensure integrity.
• Medium · Cryptographic Library Version Concerns — go.mod. Dependencies like 'golang.org/x/net v0.40.0' and 'golang.org/x/oauth2 v0.30.0' may not be the latest versions. Network and OAuth2 libraries are security-critical and should be kept current. Fix: Run 'go get -u' or use automated dependency scanning tools to identify and update to the latest secure versions of golang.org/x packages.
• Low · Release Script in Repository — hack/release.sh. The 'hack/release.sh' script is committed to the repository. Release scripts may contain sensitive operations or environment variable handling that could expose credentials if not properly secured. Fix: Review the release.sh script for any hardcoded secrets or credential handling. Use secure CI/CD practices for releases. Consider moving release logic to CI/CD pipelines with proper secret management.
• Low · Test Data in Repository — integration/context/*, examples/*. Integration test files and sample files are committed (integration/context/, examples/). While typically safe, these should be reviewed to ensure no sensitive data or credentials are accidentally included. Fix: Regularly audit test and example files for sensitive data. Use .gitignore patterns to prevent accidental commits of secrets or credentials.
• Low · — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.