Audit logging

The Anjuna Policy Manager (APM) records attestation activity through Vault’s audit log. Each attestation produces structured audit entries that identify the Anjuna Confidential Container, the attestation result, and the correlation between the challenge, authentication, and secret access steps.

Vault’s audit log provides an append-only record of every authenticated operation, including which identity accessed which secret and when. In the context of APM, this means every attestation attempt and every secret delivered to an Anjuna Confidential Container is recorded and traceable. This is particularly useful for compliance evidence, incident investigation, and verifying that secrets were only accessed by attested Anjuna Confidential Containers. See the Vault audit device documentation for how to enable and configure audit devices.

Attestation flow

Remote attestation is a two-step challenge-response exchange between the Anjuna Confidential Container and APM. First, the Anjuna Confidential Container calls the init endpoint to receive a cryptographic challenge. Then, it calls the auth endpoint with an attestation report that answers the challenge. If the attestation report is valid and the Anjuna Confidential Container’s measurements match an authorized policy, APM returns a Vault token scoped to the Anjuna Confidential Container’s authorized secrets.

Each step produces a request and response audit entry, four entries per attestation. When the issued token is subsequently used to read secrets, those requests produce additional audit entries.

APM audit fields

APM augments its Vault responses with the following fields:

Endpoint Response fields

auth/apm/v0/attest/<platform>/init (challenge)

data.correlation_id, message

auth/apm/v0/attest/<platform>/auth (success)

data.correlation_id, data.enclave_id, data.signer_id, message, plus the issued token and entity in the auth block

auth/apm/v0/attest/<platform>/auth (failure)

data.correlation_id, error; the auth block is absent

Correlating attestation events

APM emits several identifiers that link audit entries together.

Correlating the attestation flow

The data.correlation_id field uniquely identifies a single remote attestation exchange. Both the init and auth response entries carry the same value, making it the primary field for pairing an authentication back to the challenge that preceded it.

The challenge response contains the correlation_id:

{
  "type": "response",
  "request":  { "path": "auth/apm/v0/attest/<platform>/init" },
  "response": {
    "data": {
      "data": { "correlation_id": "ffd4e5a3-...-8b7ed75a996c" }
    }
  }
}

The authentication response carries the same correlation_id, along with the Anjuna Confidential Container’s measurements and the issued token:

{
  "type": "response",
  "request":  { "path": "auth/apm/v0/attest/<platform>/auth" },
  "response": {
    "auth": {
      "accessor":     "hmac-sha256:ba59...",
      "entity_id":    "29e37713-...-53f38a13803f",
      "display_name": "apm-anjuna-entity-<signer-id>-<enclave-id>"
    },
    "data": {
      "data": {
        "correlation_id": "ffd4e5a3-...-8b7ed75a996c",
        "enclave_id":     "<enclave-id>",
        "signer_id":      "<signer-id>"
      }
    }
  }
}

On a failed attestation, the response carries no auth block and no container measurements.

Tracing secret access

Once an Anjuna Confidential Container receives a token, subsequent secret reads produce their own audit entries. Two fields link these entries back to the attestation that issued the token:

The auth.accessor field uniquely identifies the specific issued token. This value is unique per run of an Anjuna Confidential Container. It appears on the auth entry and on every subsequent secret-access entry, and can be used to trace all secret access to the exact attestation that issued the token.

The auth.entity_id field is derived deterministically from the signer ID and enclave ID. Like accessor, it appears on the auth entry and on every subsequent secret-access entry. Unlike accessor, it is not unique per run: distinct runs of an Anjuna Confidential Container with the same image and configuration share the same entity_id. It can be used to find all secret access by any run of a specific Anjuna Confidential Container.

{
  "type": "response",
  "request": {
    "path": "anjuna/<secret-path>",
    "client_token_accessor": "hmac-sha256:ba59..."
  },
  "auth": { "entity_id": "29e37713-...-53f38a13803f" }
}

Configuring plaintext APM fields

Vault hashes response data in the audit log by default. To make APM’s correlation fields readable in plaintext, the auth/apm mount must be tuned to exempt appropriate response keys:

$ vault auth tune \
      -audit-non-hmac-response-keys=correlation_id \
      -audit-non-hmac-response-keys=enclave_id \
      -audit-non-hmac-response-keys=signer_id \
      apm/

The same flags can be passed to vault auth enable when mounting the APM plugin for the first time.

For diagnostic purposes, the attestation evidence (message) and verification error detail (error) can also be exempted. The message field contains base64-encoded binary attestation evidence and may be excessively large for your audit log.