Update Sovereign Cloud Challenge 4 and 5 walkthroughs

03-Azure/01-03-Infrastructure/01_Sovereign_Cloud/challenges/challenge-04.md

@@ -1,24 +1,32 @@
-# Challenge 4 - Encryption in use with Azure Confidential Compute – VM
+# Challenge 4 - Runtime attestation with Confidential ACI
 
 ## Goal
 
-Validate guest attestation on a pre-provisioned Azure Confidential VM to confirm that business logic only executes in a trusted, hardware-backed confidential computing environment. You will inspect the VM's security configuration, connect through Azure Bastion using username/password credentials, build and run a sample attestation application, and verify the cryptographic JWT proof of VM integrity using a dedicated Microsoft Azure Attestation (MAA) provider.
+Deploy the same visual attestation application to Confidential and Standard
+Azure Container Instances (ACI). Use the side-by-side result to prove that
+runtime attestation depends on AMD SEV-SNP hardware rather than application
+logic alone.
 
 ## Actions
 
-* Inspect the pre-provisioned Confidential VM security settings (security type, secure boot, vTPM, no public IP)
-* Connect to the Confidential VM via Azure Bastion using username/password credentials from your lab dashboard
-* Install dependencies, build, and run the CVM guest attestation sample application
-* Inspect the attestation token JWT claims to verify the confidential computing environment
+- Build the visual attestation image server-side in Azure Container Registry.
+- Generate a confidential-computing enforcement policy for the image.
+- Deploy the image to Confidential and Standard ACI container groups.
+- Run attestation in both applications and compare the results.
+- Inspect the Microsoft Azure Attestation claims from the confidential instance.
+- Remove only the resources created by this challenge.
 
 ## Success criteria
 
-* Attestation token output proving the VM is running in a trusted confidential environment
+- Confidential ACI returns a signed MAA token with `x-ms-attestation-type` set to `sevsnpvm`.
+- The compliance status is `azure-compliant-uvm`.
+- Standard ACI fails because `/dev/sev-guest` is unavailable.
+- Both instances use the same container image.
 
 ## Learning resources
 
-* [Azure confidential computing](https://learn.microsoft.com/azure/confidential-computing/)
-* [Azure encryption overview](https://learn.microsoft.com/azure/security/fundamentals/encryption-overview)
-* [Azure Confidential Computing Overview](https://learn.microsoft.com/azure/confidential-computing/overview)
-* [Microsoft Azure Attestation](https://learn.microsoft.com/azure/attestation/overview)
-* [About Azure confidential VMs](https://learn.microsoft.com/azure/confidential-computing/confidential-vm-overview)
+- [Why Challenge 4 uses `confcom` and Docker](../walkthrough/challenge-04/CONFCOM-AND-CCE-POLICY.md)
+- [Confidential containers on Azure Container Instances](https://learn.microsoft.com/azure/container-instances/container-instances-confidential-overview)
+- [Microsoft Azure Attestation](https://learn.microsoft.com/azure/attestation/overview)
+- [Confidential computing enforcement policies](https://learn.microsoft.com/azure/container-instances/confidential-containers-attestation-concepts)
+- [Source sample: Visual Attestation Demo v2](https://github.com/Azure/confidential-computing/tree/main/aci-samples/visual-attestation-demo-v2)

03-Azure/01-03-Infrastructure/01_Sovereign_Cloud/challenges/challenge-05.md

@@ -1,24 +1,31 @@
-# Challenge 5 - Encryption in use with Confidential VMs/Node Pools in Azure Kubernetes Service (AKS)
+# Challenge 5 - Confidential workloads on AKS
 
 ## Goal
 
-Validate guest attestation on a pre-provisioned Azure Confidential VM node pool in AKS to ensure business logic only executes in trusted, compliant confidential computing environments. You'll inspect the AKS cluster and Confidential VM node pool that were deployed for you, then deploy a sample application that implements secure attestation flows. The application leverages Microsoft Azure Attestation (MAA) to validate VM integrity before executing protected business logic, demonstrating "encryption in use" capabilities.
+Deploy the Azure Voting App and a runtime attestation UI to an Azure Kubernetes
+Service cluster. Pin the user-facing workloads to an AMD SEV-SNP Confidential
+VM node pool and verify the execution environment with a fresh MAA token.
 
 ## Actions
 
-* Inspect the pre-provisioned AKS cluster and Confidential VM node pool
-* Validate node pool configuration (VM size, node image, node labels)
-* Deploy the attestation verification sample
-* Review the attestation token output
+- Deploy an AKS cluster with managed identity and automatic upgrade channels.
+- Add and label an AMD SEV-SNP Confidential VM node pool.
+- Deploy the Azure Voting App to the confidential nodes.
+- Deploy the newer runtime attestation UI to the same node pool.
+- Verify pod placement and inspect the attestation claims.
+- Remove the AKS cluster without deleting the shared attendee resource group.
 
 ## Success criteria
 
-* Attestation token output proving the App is running in a trusted confidential environment
+- Voting front-end pods run on nodes labelled `workload=confidential`.
+- The voting application is reachable through its LoadBalancer service.
+- The attestation UI returns an MAA-signed SEV-SNP token.
+- The token reports `azure-compliant-cvm` and a non-debuggable TEE.
 
 ## Learning resources
 
-* [Azure confidential computing](https://learn.microsoft.com/azure/confidential-computing/)
-* [Azure encryption overview](https://learn.microsoft.com/azure/security/fundamentals/encryption-overview)
-* [Azure Confidential Computing Overview](https://learn.microsoft.com/azure/confidential-computing/overview)
-* [Microsoft Azure Attestation](https://learn.microsoft.com/azure/attestation/overview)
-* [Confidential containers on Azure](https://learn.microsoft.com/azure/confidential-computing/confidential-containers)
+- [When Confidential VM Orchestrator is required](../walkthrough/challenge-05/CVM-ORCHESTRATOR.md)
+- [Use Confidential VMs in AKS](https://learn.microsoft.com/azure/aks/use-cvm)
+- [AKS confidential computing overview](https://learn.microsoft.com/azure/aks/confidential-computing-overview)
+- [Microsoft Azure Attestation](https://learn.microsoft.com/azure/attestation/overview)
+- [Source sample: Azure Voting App on confidential AKS nodes](https://github.com/Azure/confidential-computing/tree/main/aks-samples/azure-voting-app)

03-Azure/01-03-Infrastructure/01_Sovereign_Cloud/walkthrough/challenge-04/.gitignore

@@ -0,0 +1,2 @@
+/acr-config.json
+/side-by-side-compare.html

03-Azure/01-03-Infrastructure/01_Sovereign_Cloud/walkthrough/challenge-04/CONFCOM-AND-CCE-POLICY.md

@@ -0,0 +1,159 @@
+# Why Challenge 4 uses `confcom` and Docker
+
+This supplement explains the Confidential Computing Enforcement (CCE) policy in
+Challenge 4 from two perspectives. It is not an additional task and does not add
+commands to the walkthrough.
+
+## The short answer
+
+For the custom Confidential Azure Container Instances (ACI) deployment used in
+this challenge:
+
+- A CCE policy is part of the Azure confidential-container security model.
+- Microsoft's supported tool for generating that policy is the Azure CLI
+  `confcom` extension.
+- The policy generator uses a local Docker engine to inspect the exact container
+  image and calculate its permitted layer hashes.
+- Docker is needed while preparing the deployment. It is not installed in the
+  ACI container group and is not needed by the application at runtime.
+- Standard ACI does not use this CCE policy flow. That is why the Standard side
+  of the comparison can deploy without confidential-policy generation.
+
+## For a business reader
+
+### The problem being solved
+
+Memory encryption answers an important question: "Can the cloud host read the
+workload's data while it is being processed?"
+
+It does not, by itself, answer another equally important question: "Is the
+approved workload actually the software running inside that protected memory?"
+
+A malicious or accidental change could replace an image, alter its startup
+command, add a mount, or inject an environment variable. Hardware might still
+protect that changed workload from the host. The organization would have a
+strong vault around the wrong program.
+
+The CCE policy closes that gap. It is a machine-enforced allow-list describing
+what may run inside the trusted environment. Azure checks the requested
+container group against that policy before allowing it to start.
+
+### Business value
+
+The policy turns "Azure says this is confidential hardware" into a more useful
+assurance: "This approved workload is running on confidential hardware under
+these approved conditions."
+
+That supports:
+
+- controlled processing of regulated or commercially sensitive information;
+- collaboration where data owners do not fully trust every infrastructure
+  operator;
+- release of secrets only after the environment proves its identity and policy;
+- stronger change control for images, commands, mounts, and configuration;
+- evidence that a relying party can evaluate before sharing data.
+
+### What happens without this mechanism
+
+Without a verifiable execution policy, confidential hardware can protect data
+from the host but cannot prove that an unexpected workload was not substituted.
+An image or configuration change could process or disclose data differently
+while still benefiting from memory encryption.
+
+For Confidential ACI, policy enforcement is fail-closed. If the deployed image
+or runtime settings do not match the generated policy, the container does not
+start. The `deviceHash not found` error seen during testing is an example: the
+policy described different image layers from those ACI attempted to mount.
+
+## For a technical reader
+
+### Standard ACI behavior
+
+A conventional ACI deployment contains an image reference and runtime settings
+such as command, environment variables, mounts, capabilities, and ports. Azure
+pulls the image and starts the requested container. Azure Resource Manager RBAC,
+registry authorization, deployment history, and operational controls govern who
+can change that configuration.
+
+Those controls are important, but they do not produce hardware-bound evidence
+that the running container exactly matches an approved configuration.
+
+### What Confidential ACI adds
+
+Confidential ACI runs the container group in an AMD SEV-SNP protected utility VM.
+The trusted execution environment protects data in use. A CCE policy adds
+container-level integrity by declaring the components and actions the
+confidential runtime permits.
+
+In this challenge, `az confcom acipolicygen`:
+
+1. Reads the temporary ARM template and its parameter file.
+2. Resolves the container images through the local Docker engine.
+3. Inspects and hashes the image layers.
+4. Includes permitted commands, environment rules, mounts, capabilities, and
+   related runtime properties.
+5. Produces a Rego policy encoded as Base64.
+6. Writes that value into `confidentialComputeProperties.ccePolicy` in the
+   temporary template.
+
+Azure deploys the template and the confidential runtime enforces the policy.
+The attestation evidence also binds the environment to the policy, allowing a
+relying party to check the policy associated with the attested workload.
+
+### Is `confcom` an Azure requirement?
+
+For the custom CCE policy used by Confidential ACI, yes. Microsoft documents
+that ACI CCE policies must be generated by the Azure CLI `confcom` extension and
+must not be authored manually. `confcom` is deployment tooling; it is not an
+agent running inside the application container.
+
+### Is Docker an Azure requirement?
+
+Docker is a prerequisite of the documented local `confcom` policy-generation
+workflow, not a general requirement of Azure Resource Manager or the running
+ACI workload.
+
+The distinction in this challenge is:
+
+| Operation | Local Docker required? | Why |
+|-----------|------------------------|-----|
+| `az acr build` | No | ACR builds the image remotely. |
+| Standard ACI deployment | No | Standard ACI does not generate a CCE policy. |
+| `az confcom acipolicygen` | Yes | The tool inspects and hashes image layers through a local Docker engine. |
+| Running application in ACI | No | Azure runs the resulting image and enforces the submitted policy. |
+
+Azure Cloud Shell does not provide a Docker daemon, so Microsoft's documented
+workflow requires Azure CLI and Docker Engine on a local computer.
+
+### Why cleanup matters before a rerun
+
+`confcom` can use a locally cached image. If an ACR tag points to newly built
+content while Docker still holds older content under the same tag, policy hashes
+can differ from the layers ACI pulls. Azure then rejects the container startup.
+
+Challenge 4 uses a simple lifecycle:
+
+```powershell
+./Deploy-VisualAttestationV2.ps1 -Build
+./Deploy-VisualAttestationV2.ps1 -Compare
+./Deploy-VisualAttestationV2.ps1 -Cleanup
+```
+
+Cleanup removes the tagged local image as well as the Challenge 4 Azure
+resources. Run it before rebuilding with the same workshop values.
+
+### What a CCE policy does not replace
+
+A CCE policy does not replace image vulnerability scanning, image signing,
+software supply-chain controls, identity and access management, network
+security, encryption at rest, or validation of the Microsoft Azure Attestation
+token by a relying application. It supplies a specific control: enforce and
+attest the allowed confidential-container runtime configuration.
+
+## Official references
+
+- [Confidential containers on Azure Container Instances](https://learn.microsoft.com/azure/container-instances/container-instances-confidential-overview)
+- [Prepare a Confidential ACI deployment and generate a CCE policy](https://learn.microsoft.com/azure/container-instances/container-instances-tutorial-deploy-confidential-containers-cce-arm)
+- [Attestation concepts for Confidential ACI](https://learn.microsoft.com/azure/container-instances/confidential-containers-attestation-concepts)
+- [Troubleshoot Confidential ACI policy and image hash errors](https://learn.microsoft.com/azure/container-instances/container-instances-troubleshooting#issues-during-confidential-container-group-deployments)
+- [`az confcom` command reference](https://learn.microsoft.com/cli/azure/confcom)