"Remote attestation", one of these important elements, often gets only mentioned briefly due to time constraints. However, it's a vital cornerstone of confidential computing that I think deserves its own dedicated blog post. This post does just that and focusses on the Remote ATtestation Procedures (RATS) architecture, as outlined in IETF RFC 9334, and its connection to Microsoft Azure Attestation (MAA). Additionally, we explore the deployment of both the AAD and Isolated models within the Microsoft Azure Attestation service. Using PowerShell, we generate a random RSA key pair that enables us to deploy a signer certificate, allowing us to sign customized attestation policies.
The Microsoft Azure Attestation (MAA) service operates within three distinct trust models, each defining the authorization model for attestation providers in terms of creating and updating appraisal policies.
- Shared
- Azure AD (AAD) authorization
- Isolated
The primary distinction among these modes of operation lies in the usable operations within each, and whether the customer is required to create an instance of the provider.
| Service Mode | Instance Creation | Attestation | Policy Get | Policy Set | Signed Policies | Policy Management Certificate |
|---|---|---|---|---|---|---|
| Shared | No | Yes | Yes | No | No | No |
| AAD | Yes | Yes | Yes | Yes | Optional | No |
| Isolated | Yes | Yes | Yes | Yes | Yes | Yes |