Create or update policies

After you have defined your identities, the next crucial step is to create a policy. This policy will be used during the attestation verification process to determine if a workload meets the defined security requirements.

Prerequisites

• Install and configure Nitride.

• Install vHSM CLI.

• Install curl and jq tools.

• Log in as root user to use the vHSM CLI tool, else use the root token for vHSM instance to use curl.

• Create an identity.

Create a policy named test , that includes:

• The provider field under "identities" to the correct value for your environment (e.g., "aws-sev-snp-raw" for AWS, or "azure-sev-snp-vtpm" for Azure). In this example it is "local-none-debug" for your local system.

• The name of the platform and firmware identities you have already created. If you don't have a specific type of identity, set its value to null.

vHSM CLI

vhsm write auth/ratls/policies - <<'EOF'
{
  "name": "test",
  "identities": {
    "provider": "local-none-debug",
    "firmware": [
      {
        "name": "test-local"
      }
    ],
    "workload": null,
    "metadata": null
  }
}
EOF

cURL

This method is more universal and directly interacts with the API endpoint. Remember to replace <hvs.XXXX >with your valid authentication token.

curl -H "X-Vault-Token: hvs.XXXX" \
    http://127.0.0.1:8200/v1/auth/ratls/policies \
    --data '{"name":"test","identities":{"provider":"local-none-debug","firmware":[{"name":"test-local"}],"workload":null,"metadata":null}}'

The output is similar to:

vHSM CLI

Key           Value
---           -----
created       1734560736
identities    map[firmware:[map[name:test-local policy:<nil>]] metadata:<nil> platform:[map[name:amd-sev-snp-milan-vlek policy:<nil>]] provider:aws-sev-snp-raw workload:<nil>]
name          test

cURL

{
  "request_id": "2fef9b94-ae6e-c2ce-3d5a-bce1232e2399",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "created": 1749558589,
    "identities": {
      "firmware": [
        {
          "name": "test-local",
          "policy": null
        }
      ],
      "metadata": null,
      "platform": null,
      "provider": "local-none-debug",
      "workload": null
    },
    "name": "test"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Possible Error Response

If there's an issue with the request, such as invalid data, you might receive an error.

{
  "errors": [
    "Invalid request"
  ]
}

Description of Nested Identity Objects in Policy

Within the identities object of your policy, the nested objects for platform, firmware, workload, and metadata are defined as follows:

Field	Description
name	This is the name of the identity suchas "test", and "amd-sev-snp-milan-vlek" that you created using the identity creation endpoint.
policy	This is an optional field that allows you to specify fine-grained control over which parts of the identity are actually used for the verification within this specific policy. By default, verification of all fields is enabled. You can disable verification for specific nested fields using a path notation similar to jq . For example, "pcrs.1": false to disable verification for PCR index 1. If null or not present, all fields within that identity as defined in its values are used for verification. { "name": "vtpm", "policy": { "hash": false, "pcrs.1": false } }

Array of Identities: Some identity types such as platform and firmware allow an array of identities to be specified. This means that if any of the identities in the array pass attestation, the overall policy for that type is considered satisfied.