Can you trace the add-on running in your cluster?

A backup agent may need broad access to a cluster. A monitoring add-on may read information across namespaces. These are useful tools, but installing them also means trusting the software, its dependencies, and the process that delivered it.

The question is worth asking before the next install: can you trace the image that is about to run back to the exact artifact you approved?

Approve an artifact you can identify

A version label is convenient for people. A content digest identifies the image bytes. Keeping the approved digest through scanning, signing, and deployment helps prevent an image from changing between those steps.

A private registry gives the operator a controlled distribution point. It also creates work: tracking upstream fixes, refreshing scans, and deciding when an approved image must be replaced. Copying an image into a private registry does not itself make the image safe.

Keep the scan result attached to the decision

Moncho’s add-on pipeline uses two vulnerability scanners, checks known-exploited vulnerabilities and secrets, and reviews chart configuration. Accepted artifacts are signed with a platform-held key before promotion.

Two scanners can provide useful coverage, but neither guarantees that an image is free of vulnerabilities. Findings need a decision: patch, block, or accept a documented exception where the policy permits one. The evidence should identify which artifact was scanned and why it was accepted.

That link matters when a pipeline is resumed after a failure. A completed scan of one image cannot authorize a different image simply because both use the same release name.

Check the signature where the workload is admitted

Signing provides little protection if the cluster never checks the signature. Moncho verifies its catalog images through admission policy inside tenant clusters. An image in the governed catalog scope without the required signature is rejected.

The scope matters. This is a control over the platform’s add-on supply chain, not a claim that every workload a tenant runs has been approved by Vigilus. Tenants can run their own software under their cluster permissions.

A signature has a specific meaning

A valid signature ties the artifact to a signing key. It does not certify that the program is harmless, that its configuration is appropriate, or that no vulnerability will be discovered tomorrow. Key custody and release review remain part of the control.

Moncho uses self-held signing keys and verification without a runtime dependency on an external public signing service. Its admission policies are restored when configuration drifts, but this is not an unbreakable boundary against a tenant with cluster-administrator rights. Already-running workloads are not continuously re-verified by an admission check.

Ask for a rejection as well as a successful install

In an evaluation of Moncho, ask to follow one catalog artifact from its scan result to its running digest. Then attempt to deploy an unapproved catalog image. Check what happens if verification is unavailable, too: a policy that blocks deployment needs operational support when its verifier fails.

The useful outcome is a release process you can inspect and repeat, with clear ownership when a new vulnerability changes the approval decision.