Policy

Learn more about policies to verify attestation claims.

Policies in confidential computing serve as the trust framework that defines the acceptable criteria for verifying attestation claims. They act as the rulebook that determines whether a workload's identity and integrity claims are trustworthy enough to grant access to sensitive resources or establish secure communication channels.

Core Concept

A policy is a structured set of rules and requirements that specify:

• Which platform identities are acceptable

• What firmware measurements are trusted

• Which workload configurations are permitted

• What metadata must be present and validated

Think of policies as the "security guard" that examines the workload's attestation report and decides whether to grant or deny access based on predefined trust criteria.

Policy Structure in Nitride

Similar to how workload identity is constructed from four foundational components, policies are structured to validate each of these components:

1. Platform Identity Validation:

It serves to verify that the hardware platform is from a trusted manufacturer and model, ensuring the underlying infrastructure meets security requirements. For example, this validation might only allow AMD SEV-SNP Milan processors with valid VCEK certificates, implementing strict hardware controls. The validation process involves comprehensive checks of platform measurements, certificates, and attestation signatures to establish trust in the hardware foundation before any workload execution begins.

2. Firmware Identity Validation

The purpose of firmware validation is to ensure that the firmware, such as the BIOS or bootloader, originates from a trusted source and has not been tampered with. For instance, a policy might require specific firmware measurements from Azure DC2as v5 instances to guarantee authenticity. This validation process involves comparing the firmware measurements reported by the system against known good values, thereby confirming the integrity and trustworthiness of the firmware before allowing further operations.

3. Workload Identity Validation

The purpose of workload validation is to verify the actual application code and its configuration, ensuring that only trusted workloads are allowed to run. For example, a policy might permit only specific Ubuntu Jammy workloads that present certain PCR values, thereby restricting execution to known and approved software environments. This validation process involves checking workload measurements, cryptographic hashes, and runtime configurations to confirm that the workload matches the expected and authorized state.

4. Metadata Validation

The purpose of metadata validation is to ensure that additional contextual information associated with a workload meets defined security requirements. For example, a policy might require that workloads specify a particular namespace, deployment environment, or include certain compliance tags. This validation process involves verifying that the metadata fields provided by the workload match the expected values, thereby adding an extra layer of assurance that the workload is operating within the correct and authorized context.

How Policies Work with Attestation

1. Attestation Report Generation

When a workload starts, it generates an attestation report containing:

• Platform measurements and certificates

• Firmware measurements

• Workload code measurements

• Runtime environment metadata

2. Policy Evaluation

The policy engine evaluates the attestation report against the defined policy:

Attestation Report → Policy Rules → Trust Decision

3. Trust Decision

Based on policy evaluation, the system decides:

• Allow: All measurements match policy requirements

• Deny: One or more measurements fail policy validation

• Quarantine: Partial matches requiring additional verification

Example Policy in Practice

{
  "name": "azure-sev-snp-milan-vcek-vtpm-ubuntu-jammy",
  "identities": {
    "provider": "azure-sev-snp-vtpm",
    "platform": [
      {
        "name": "amd-sev-snp-milan-vcek"
      }
    ],
    "firmware": [
      {
        "name": "azure-dc2as-v5"
      }
    ],
    "workload": {
      "name": "azure-sev-snp-vtpm-ubuntu-jammy",
      "policy": {
        "hash": false,
        "pcrs.0": false
      }
    }
  }
}

Note: This policy would only permit Azure SEV-SNP VTPM workloads that are running on AMD Milan processors with valid VCEK certificates, utilizing Azure DC2as v5 firmware, and configured with a specific Ubuntu Jammy workload setup.

Benefits of Policy-Based Verification

Policies offer several key benefits in confidential computing environments. They provide:

• granular control : by allowing organizations to define different trust levels for various workloads and implement least-privilege access based on workload identity.

• Automate compliance: is achieved as security policies are enforced automatically, ensuring that all workloads consistently meet organizational security standards.

• Support a zero-trust architecture: policies ensure that trust is never assumed; instead, every workload is continuously validated for integrity.

Additionally, policies enable a comprehensive audit trail, maintaining a complete record of attestation decisions and supporting compliance and security monitoring efforts.

Integration with Zero-Trust

Policies enable true zero-trust architectures by eliminating implicit trust, requiring every workload to prove its identity through continuous verification where policies are evaluated on every access attempt. This approach provides dynamic trust capabilities, allowing trust levels to be adjusted based on changing security requirements, while implementing defense in depth through multiple layers of verification across platform, firmware, workload, and metadata components. This policy-driven approach ensures that only workloads meeting strict security criteria can access sensitive resources, creating a robust foundation for confidential computing environments.