Cosign and External Secrets Operator: a Kubernetes supply-chain baseline for MSPs

This guide pairs two open-source controls MSPs can apply across a managed Kubernetes fleet: signing and verifying container images with Sigstore Cosign, and keeping credentials out of Git with the External Secrets Operator. Used together, they close two of the most common gaps in a Kubernetes supply chain — unverified images and hard-coded secrets in manifests — without a new platform or vendor lock-in.

Sign at build, verify at deploy

Cosign, part of the open-source Sigstore project, signs and verifies container images so a Kubernetes cluster can confirm an image came from an approved build pipeline before it runs. The pattern that matters for MSPs is simple: sign every image at build time, then verify that signature at admission or deploy time, and reject anything that does not check out.

Signing can use long-lived keys that a security team controls, or Sigstore's keyless flow, in which Fulcio issues a short-lived certificate binding an ephemeral key to a verified OpenID Connect identity — a CI system or a person — while Rekor's transparency log timestamps the event. Verification then happens where an image is about to run: an admission controller or deploy gate checks the signature against an approved identity or key, and blocks anything unsigned or untrusted from reaching a managed cluster.

What signing does not replace

A signature proves provenance — that a specific digest came from a specific pipeline or identity — but it says nothing about whether that digest contains known vulnerabilities. Cosign is meant to sit alongside an image scanner such as Trivy or Grype, not instead of one: the scanner judges what is inside the image, the signature proves where it came from. Treating "signed" as synonymous with "safe" leaves half the control missing.

Keeping secrets out of Git with External Secrets Operator

External Secrets Operator is a Kubernetes controller that bridges external secret managers — among them AWS Secrets Manager, HashiCorp Vault and Azure Key Vault — with native Kubernetes Secrets, so credentials never need to sit in a Git repository or a Helm chart. It watches a SecretStore or ClusterSecretStore resource and syncs values into Kubernetes Secrets on a schedule, without the operator itself needing to log the plaintext.

Scoping each ExternalSecret to the namespace and workload that actually needs it limits the blast radius if a pod is compromised. The operator still depends on the underlying secrets manager's own access controls and rotation policy: it moves credentials out of version control, it does not replace a secrets manager's security posture.

Why the pairing matters for MSPs

Managed Kubernetes fleets tend to accumulate both problems at once: secrets hard-coded for convenience, and images pulled from a registry without a signature check. Wiring External Secrets into the deployment path removes the excuse for storing credentials in manifests, while a Cosign admission policy gives an MSP a single, auditable gate for whether an image came from its own pipeline.

Neither tool is a complete security program on its own. Cosign verification is only as strong as the key management and issuer trust behind it, and least privilege, network segmentation and incident response remain separate work. Treated together, though, the two controls form a repeatable baseline that can be applied per tenant, with a documented exception process for anything that does not yet comply.

MSPs that need to demonstrate these controls hold up under audit can turn to Altovar's cybersecurity services, which cover penetration testing, vulnerability assessment, incident response and NIS2/DORA/GDPR compliance.

What to do

• Sign every image at build time and verify it again at admission or deploy; never trust a signature from the build step alone.
• Test the failure path first: confirm that an unsigned or tampered image is actually rejected before trusting the gate in production.
• Pair Cosign with a vulnerability scanner such as Trivy or Grype, since a valid signature is not the same as a clean scan.
• Move every credential out of manifests and Helm charts into an External Secrets Operator-managed SecretStore.
• Scope each ExternalSecret to the namespace and workload that needs it, and rotate keys or credentials on a defined schedule.
• Document the exception process for anything that does not yet comply, and validate policy changes in a non-production cluster before rolling them out fleet-wide.

Sources: GitHub — sigstore/cosign, Sigstore docs, External Secrets Operator on GitHub.