Three identity planes: humans, cloud APIs, and workloads
Confidential AI systems fail open when “identity” means only an interactive login. In CAN we separate three planes so policies stay least-privilege and portable.
1. Humans and the portal
Interactive users (Training Data Consumer, Training Data Provider, Tech Service Provider / clean-room operator, AppAdmin) authenticate with the cloud identity provider:
| Cloud | Identity provider |
|---|---|
| Azure | Microsoft Entra ID |
| OCI | OCI IAM Identity Domains |
| GCP | Identity Platform |
| AWS | Cognito |
Keycloak stays on the laptop for demos and automated tests — it is not the production identity provider on any cloud.
2. Workloads calling cloud control planes
Pods and jobs need Key Vault, Blob, and registries without static API keys. On Azure that is AKS Workload Identity and/or Entra Workload Identity Federation (SPIRE issues a short-lived JWT-SVID, exchanged for a short-lived Entra access token). On Oracle Cloud that is OKE Workload Identity and/or IAM Workload Identity Federation.
3. Workload-to-workload Zero Trust
Peers (backend ↔ trainer ↔ confidential clean room) prove who they are with SPIFFE/SPIRE verifiable identity documents and mutual TLS. SPIFFE does not replace Trusted Execution Environment attestation for data/model encryption-key release — it complements it.