Admission policies

Loha signs the images that pass the security gate (image signing). An admission policy carries that trust into your cluster. With the policy Loha generates, your admission controller refuses images from your Loha-built repositories that Loha did not sign.

Loha installs nothing in your cluster and never applies the policy for you.

Loha generates the policy for two admission controllers:

Admission controller	Resource	Version
Kyverno	ImageValidatingPolicy (policies.kyverno.io/v1)	not usable yet (see warning)
Sigstore policy-controller	ClusterImagePolicy (policy.sigstore.dev/v1beta1)	current

Kyverno cannot check the provenance yet

Kyverno up to at least 1.19.1 cannot verify Loha's provenance attestation. Loha signs without a transparency log, and Kyverno's attestation check ignores insecureIgnoreTlog (upstream issue kyverno/kyverno#17109). Until a Kyverno release fixes this, a Kyverno policy refuses every Loha image in enforce mode and reports every Loha image in audit mode. Use the Sigstore policy-controller.

What the policy checks

The policy checks every pod in a namespace you opted in. For each image that comes from one of the policy's repositories, it requires:

• a signature from one of your workspace keys: the active key, a retired key, or the next key of a staged rotation, but never a revoked key;
• a SLSA provenance attestation (https://slsa.dev/provenance/v1), signed with one of those keys, that names a Loha builder.

Images from other repositories are not checked by this policy.

The repositories in the policy are the ones where Loha has signed at least one image, plus any an admin adds under Code security settings → Admission policy. Loha signs without a public transparency log, so the policy does not look for one.

Download the policy

• UI: Code security settings → Admission policy. Choose the admission controller and the mode, then select Download policy.
• CLI: loha images policy --engine sigstore --mode audit > loha-policy.yaml
• API: GET /api/v1/security/admission-policy?engine=sigstore&mode=audit. Use a token with security:read that is not limited to one project. The X-Loha-Policy-Version response header carries the version.

The policy is ready once Loha has signed at least one image in the workspace. Until then, the page and the CLI say what is missing.

Each policy carries its version in the loha.cloud/policy-version annotation. The settings page shows the current version. Compare it with what your cluster runs:

# Sigstore policy-controller
kubectl get clusterimagepolicies -o custom-columns='NAME:.metadata.name,VERSION:.metadata.annotations.loha\.cloud/policy-version'
# Kyverno
kubectl get imagevalidatingpolicies -o custom-columns='NAME:.metadata.name,VERSION:.metadata.annotations.loha\.cloud/policy-version'

Roll it out safely

1. Install the admission controller: Kyverno 1.17 or later, or the Sigstore policy-controller. It needs pull access to your registry to read signatures.

   • Kyverno reads registry credentials from secrets in its own namespace that its admission controller names with --imagePullSecrets.
   • The policy-controller uses the pod's image pull secrets.

2. Apply the policy in audit mode: kubectl apply -f loha-policy.yaml.

3. Opt one namespace in.

   • Kyverno: kubectl label namespace <namespace> loha.cloud/verify-images=true

   • Sigstore policy-controller: kubectl label namespace <namespace> policy.sigstore.dev/include=true.

     In an opted-in namespace, the policy-controller refuses any image that no policy matches, unless no-match-policy is warn or allow in its config-policy-controller ConfigMap. Set it to warn, unless you already have policies for every image that runs there.

4. Read what audit mode reports.

   • Kyverno writes policy reports: kubectl get policyreports -n <namespace>.
   • The policy-controller returns warnings to kubectl and logs them.

   Fix every image that would be refused. An unsigned image in a checked repository usually comes from a build outside Loha, or from a build whose image Loha could not sign (see the attestation state on the build's Security tab).

5. Switch to enforce. Download the policy again in enforce mode and apply it. Then label more namespaces, one at a time.

Key rotation

When an admin rotates the workspace signing key, Loha stages the new key:

• The new key appears in the policy at once, as the next key. It signs nothing yet.
• It starts signing after 7 days, or earlier if an admin activates it under Signing keys.
• Workspace owners and admins get an email whenever the policy version changes. Download the policy again and apply it to every cluster before the new key starts signing. A cluster that still runs an older policy refuses images signed with the new key.

Activating the next key does not change the policy version, because the policy already trusts both keys.

Revocation is immediate. Rotating with revoke takes the current key out of the policy at once, and a staged key, if there is one, starts signing at once. Apply the refreshed policy straight away. Until you do, your clusters still admit images signed with the revoked key.

You cannot yet revoke a key that is already retired.

What this does not do

• Loha does not apply the policy, and cannot see whether your cluster runs it.
• Namespaces you have not labelled are not checked.
• Images from repositories that are not in the policy are not checked by it.
• The policy checks Loha's signature and provenance, not scan results.
  • Under Enforce, Loha signs only images that passed the security gate.
  • Under Observe, Loha signs images whose completed scans would pass your policy thresholds, and the provenance records the mode.