kapp-controller

What is kapp-controller?

The kapp-controller image packages the kapp-controller Kubernetes controller so you can run declarative continuous delivery and package management directly inside your cluster. kapp-controller is part of the Carvel toolchain — it watches for App, Package, PackageInstall, and PackageRepository custom resources and continuously reconciles them, fetching application configuration from Git repositories, OCI registries, or Helm charts, applying templating via ytt or Helm, and deploying the result with kapp. This makes it the engine for GitOps-style workflows where a git push is all that's needed to trigger a reconciliation loop across your cluster. Beyond continuous delivery for individual apps, kapp-controller doubles as a Kubernetes-native package manager: software authors can bundle applications as versioned Packages distributed via OCI-based PackageRepositories, and cluster operators can discover, configure, and install them with a PackageInstall resource — similar to how apt or brew work, but declarative and Kubernetes-native. kapp-controller is also the foundation of the package management layer in VMware Tanzu Kubernetes Grid.

What is Echo's kapp-controller image?

Echo's kapp-controller image is a hardened build of kapp-controller on Echo's hardened base. Echo images are designed to be a drop-in replacement: swap the image reference in your kapp-controller deployment manifest and CVEs go to zero without disrupting your continuous delivery or package management workflows. Every image is tested across clouds, image use cases, and deployment targets. Echo ships every image in two variants:

• Distroless variant — optimized for runtime use, with the smallest possible attack surface
• Default variant — includes essential build tools, package managers, and shells for teams that need operational access

For production kapp-controller deployments, the distroless variant keeps all reconciliation operations — App CR fetching, templating, deployment, and PackageInstall lifecycle management — fully intact while minimizing exposure; the default variant suits platform teams that need shell access for controller debugging, CRD inspection, or reconciliation troubleshooting.

What is the difference between Echo's kapp-controller image and the public kapp-controller image?

Public kapp-controller images ship on bases that include OS-level tooling convenient for development and debugging but which contribute CVEs that accumulate on a controller running continuously inside your cluster with broad permissions to fetch, template, and apply resources across namespaces. GitOps controllers are among the highest-value targets in Kubernetes infrastructure — kapp-controller has access to your Git credentials, OCI registry pull secrets, and the Kubernetes API itself, with the ability to deploy any resource the controller's service account permits. A compromised kapp-controller image doesn't just expose one workload; it can be used to alter what gets deployed across your entire cluster. Echo's build retains everything kapp-controller needs for App CR reconciliation, Package lifecycle management, and OCI bundle fetching while removing the packages that don't belong in a production GitOps controller. As we covered in our post on how to protect your company from software supply chain attacks, GitOps and continuous delivery controllers sit at the most sensitive point in the delivery chain — they hold the keys to your cluster and execute whatever your source of truth tells them to. Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Echo images are recognized by all major scanners and mirrored to all major registries, so they fit into existing pipelines without changing your registry, scanner, or runtime tooling.

FAQ

Can I replace my kapp-controller image with Echo's kapp-controller image?

Yes. Echo's kapp-controller image is a drop-in replacement. Update the image reference in your kapp-controller deployment manifest — whether installed via the release YAML, Helm chart, or as part of a Tanzu cluster — and your continuous delivery and package management workflows keep running. App CR reconciliation, PackageInstall lifecycle management, OCI bundle fetching, ytt templating, and kapp-based deployment all continue to work without any changes to your existing CRDs, RBAC, or App CR configuration.

Is Echo's kapp-controller image FIPS-validated?

Yes. Echo's FIPS-validated images use cryptographic modules with an active FIPS 140-3 CMVP certificate, making them fit for federal use — unlike FIPS-compliant images that haven't been validated. This matters for platform teams running kapp-controller inside FedRAMP boundaries where a controller that fetches configuration from Git and OCI registries, applies it to the cluster, and manages credentials for multiple sources must meet cryptographic requirements.

What is Echo's vulnerability management SLA on the kapp-controller image?

Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Patches are mirrored automatically into your private registry so you're always running a clean version — critical for a GitOps controller that runs continuously with cluster-wide deployment permissions and access to Git credentials and OCI registry pull secrets.

Is Echo's kapp-controller image distroless?

Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production kapp-controller deployments, the distroless variant is the leaner, more secure choice; for platform teams that need shell access for reconciliation debugging, CRD inspection, or troubleshooting App CR fetch failures, the default variant is the right fit.

How does Echo achieve such a drastic CVE reduction in kapp-controller?

Echo's kapp-controller image is built from source with only the absolute essentials needed to run the continuous delivery and package management controller workload, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the kapp-controller version that works for your cluster without forcing a disruptive upgrade that risks breaking your App CR or PackageInstall configuration.

Will Echo's kapp-controller image help us achieve FedRAMP?

Yes. The hard parts of FedRAMP — managing vulnerabilities, applying fixes, and using FIPS-validated cryptography — are baked into Echo images, including STIG-hardened configuration and ConMon/POA&M-ready reporting. For platform teams running kapp-controller as the GitOps and package management layer under an ATO, Echo's hardened kapp-controller image keeps the continuous delivery control plane in-boundary and compliant.