Attestation verification configuration

Attestation verification options are available through the standard vault CLI, which is used to configure the Anjuna Policy Manager plugin installation.

Azure SEV-SNP trusted ID Key Digests

When an Anjuna Confidential Container based on AMD’s SEV-SNP technology is launched on Azure, the Hypervisor leverages the SEV-SNP Platform Security Processor (PSP) firmware to securely configure and launch a Confidential VM (CVM).

As part of the launch process, a unique and signed ID block is assigned to the VM by the Hypervisor. The private key used to sign this ID block is private to Azure. The ID_KEY_DIGEST is a SHA-384 hash of the corresponding public key and is advertised by the Attestation Report to help with downstream verification of the VM’s integrity. The PSP firmware validates this ID block signature to finalize the VM launch.

The Anjuna Policy Manager (APM) uses this ID_KEY_DIGEST data to verify whether an Attestation Report was created by a trusted CVM in Azure. The APM internal configuration maintains a list of ID_KEY_DIGEST values that are known at the time of the release of a specific version of the APM. When a new ID_KEY_DIGEST value is shared by Azure, Anjuna will include it in the next release of the APM.

The list of ID Key Digests trusted by the APM can be extended without the need to upgrade the APM to a newer version. This will account for future key rotations from Azure and ensure 24/7 operations for Anjuna Confidential Containers.

The Anjuna Support team will preemptively notify customers about upcoming Azure ID Key rotations and any new ID_KEY_DIGEST values.

Use the following command to update the existing APM with the new ID_KEY_DIGEST value:

vault write "auth/apm/config" azcvm-trusted-id-key-digests="<value>"

Replace <value> with the SHA-384 digest of a new public key, for example:

0356215882a825279a85b300b0b742931d113bf7e32dde2e50ffde7ec743ca491ecdd7f336dc28a6e0b2bb57af7a44a3

The command also accepts a list of values, with the following format:

vault write "auth/apm/config" \
  azcvm-trusted-id-key-digests="<value 1>" \
  azcvm-trusted-id-key-digests="<value 2>"

These values are added to the digests that ship with the APM; they do not replace them.

AMD SEV-SNP certificate revocation

An Anjuna Confidential Container based on AMD SEV-SNP presents an Attestation Report signed by a chain of AMD certificates: the AMD Root Key (ARK), the AMD SEV Key (ASK), and the per-chip VCEK. AMD publishes a Certificate Revocation List (CRL) for each CPU product line so that a compromised key can be revoked. During SEV-SNP attestation, the APM checks the report’s certificate chain against the relevant CRL and rejects any report whose chain has been revoked.

The APM performs this check on every attestation. If the APM does not have a current CRL for the report’s product line and cannot fetch one, attestation fails rather than proceeding without it. When the APM can reach AMD, this happens automatically; in offline deployments, keeping a current CRL available is an operational responsibility. The check can be suspended for a bounded period as an emergency measure; see Temporarily disabling revocation checking.

The APM obtains CRLs in one of two modes, set by the sevsnp-crl-source field:

amd-kds (default) — the APM fetches each product line’s CRL from the AMD Key Distribution Service (KDS) at kdsintf.amd.com and caches it. This requires outbound network access from the APM host to AMD KDS.
local — the APM uses only the CRLs that an operator provides. Use this mode when the APM host has no outbound access to AMD KDS, or when CRL distribution is managed centrally. For the workflow of supplying CRLs in this mode, see Seed the APM CRL cache.

Controlling how long a CRL is trusted

Each CRL carries a nextUpdate time set by AMD, the time by which AMD expects to publish a newer CRL with a higher CRL number. Once a stored CRL passes its nextUpdate time, the APM treats it as expired and requires a newer one.

The sevsnp-crl-max-age causes the APM to treat a stored CRL as expired before its nextUpdate time, which is useful when you want to refresh more often than AMD requires.

This setting is a duration measured from the time the APM stored the CRL. The default is 24h; use 168h for one week. (Durations do not support day or week units.)

A stored CRL is trusted until the earlier of its nextUpdate time or its max-age expiration. To rely solely on nextUpdate, set sevsnp-crl-max-age to 0.

To view a CRL’s built-in validity window, run:

openssl crl -inform DER -in milan.crl -noout -lastupdate -nextupdate

Fetching CRLs from AMD KDS

In amd-kds mode, no further configuration is required. The APM fetches and caches each product line’s CRL as reports are verified, and downloads a fresh CRL when the stored one expires. To set the mode and the freshness window explicitly, run:

vault write "auth/apm/config" sevsnp-crl-source=amd-kds sevsnp-crl-max-age=24h

To supply CRLs to an air-gapped APM in local mode, see Seed the APM CRL cache.

Temporarily disabling revocation checking

When a CRL problem is blocking attestation, an operator can temporarily suspend revocation checking while the underlying problem is resolved. This is appropriate when AMD KDS is unreachable in amd-kds mode, or when no current CRL is available in local mode.

This is an emergency override, not a steady-state configuration. While suspended, the APM cannot detect a revoked ASK or VCEK.

To suspend revocation checking, set sevsnp-crl-disable-for to a duration:

vault write "auth/apm/config" sevsnp-crl-disable-for=72h

The duration is capped at 168h (one week), after which revocation checking resumes automatically. Only the CRL check is suspended; the APM still verifies the rest of the certificate chain.

While the override is active, the APM logs a warning on every attestation, showing when revocation checking will resume:

[WARN]  secrets.apm.apm_a1b2c3d4: Skipping AMD SEV-SNP CRL revocation checks: disabled until 2026-06-20T14:00:00Z by operator override

Re-issuing the command resets the period from that point; it does not extend the time remaining. To keep revocation checking suspended, re-issue the command before the period ends.

To resume revocation checking immediately, set sevsnp-crl-disable-for to 0:

vault write "auth/apm/config" sevsnp-crl-disable-for=0

Configuration reference

All fields are set on the APM configuration endpoint auth/apm/config:

Field Description

Field	Description
`sevsnp-crl-source`	`amd-kds` (default) to fetch CRLs from AMD KDS, or `local` to serve only operator-supplied CRLs.
`sevsnp-crl`	One or more CRLs to store, each Base64-encoded. Accepts a list.
`sevsnp-crl-max-age`	How long a stored CRL is trusted before the APM treats it as expired (default `24h`). `0` defers to the CRL’s built-in `nextUpdate` time. See Controlling how long a CRL is trusted.
`sevsnp-crl-disable-for`	Suspends revocation checking for the given duration (max `168h`); `0` clears it. See Temporarily disabling revocation checking.

sevsnp-crl-source

amd-kds (default) to fetch CRLs from AMD KDS, or local to serve only operator-supplied CRLs.

sevsnp-crl

One or more CRLs to store, each Base64-encoded. Accepts a list.

sevsnp-crl-max-age

How long a stored CRL is trusted before the APM treats it as expired (default 24h). 0 defers to the CRL’s built-in nextUpdate time. See Controlling how long a CRL is trusted.

sevsnp-crl-disable-for

Suspends revocation checking for the given duration (max 168h); 0 clears it. See Temporarily disabling revocation checking.