Zhangyems patch 1

03-Azure/01-03-Infrastructure/01_Sovereign_Cloud/Readme.md

@@ -45,8 +45,8 @@ After completing this MicroHack you will:
 | 1         | Using Azure native platform controls (e.g. Policy, RBAC etc) to enforce sovereign controls in the public cloud | [Challenge](./challenges/challenge-01.md) | [Solution](./walkthrough/challenge-01/solution-01.md) | 45 min | Jan Egil Ring |
 | 2         | Encryption at rest with Customer Managed Keys in Azure Key Vault | [Challenge](./challenges/challenge-02.md) | [Solution](./walkthrough/challenge-02/solution-02.md) | 30 min | Ye Zhang |
 | 3         | Encryption in transit - enforcing TLS | [Challenge](./challenges/challenge-03.md) | [Solution](./walkthrough/challenge-03/solution-03.md) | 30 min | Ye Zhang |
-| 4         | Encryption in use with Azure Confidential Compute - VM | [Challenge](./challenges/challenge-04.md) | [Solution](./walkthrough/challenge-04/solution-04.md) | 90-120 min | Murali Rao Yelamanchili |
-| 5         | Encryption in use with Confidential VMs/Node Pools in Azure Kubernetes Service (AKS) | [Challenge](./challenges/challenge-05.md) | [Solution](./walkthrough/challenge-05/solution-05.md) | 90-120 min | Murali Rao Yelamanchili |
+| 4         | Runtime attestation with Confidential Azure Container Instances | [Challenge](./challenges/challenge-04.md) | [Solution](./walkthrough/challenge-04/solution-04.md) | 30-45 min | Murali Rao Yelamanchili |
+| 5         | Confidential workloads and runtime attestation on Azure Kubernetes Service (AKS) | [Challenge](./challenges/challenge-05.md) | [Solution](./walkthrough/challenge-05/solution-05.md) | 30-45 min | Murali Rao Yelamanchili |
 | 6         | Operating Sovereign in a hybrid environment with Azure Local and Azure Arc | [Challenge](./challenges/challenge-06.md) | [Solution](./walkthrough/challenge-06/solution-06.md) | 60-90 min | Jan Egil Ring / Thomas Maurer |
 
 ### General prerequisites
@@ -69,12 +69,10 @@ The main cost driver for this MicroHack is virtual machines:
 
 - **ArcBox for ITPro** cost is approximately 7 USD per day. We recommend setting it up the week before the event, so for example 5 days before the event would result in a cost between 30-40 USD.
 - **LocalBox** cost is approximately 100-110 USD per day. We recommend setting it up the week before the event, so for example 5 days before the event would result in a cost between 5-600 USD.
-- Challenge 4 and 5 contains a Confidential Compute VM (Standard_DC2as_v5) which costs approximately 5 USD per day. These 2 VMs will run only for a few hours as they will be created by the students, so using 50 students as an example running the VMs for 8 hours would results in 2 VMs x 8 hours = 230 USD.
+- Challenge 4 uses two short-lived Azure Container Instances and a Basic Azure Container Registry. Challenge 5 creates one `Standard_D2as_v6` AKS system node and two `Standard_DC2as_v5` confidential nodes by default, plus two public LoadBalancer services. These resources run only for a few hours and should be deleted after each challenge.
 
-This would result in a total cost of 789 USD.
-In addition, there would be some smaller costs for other services like Key Vault, so a rough estimate is 1000 USD for one Sovereign Cloud MicroHack if following the above example.
-An Azure Pricing Calculator estimate is available [here](https://azure.com/e/1a7aec76a3e049cba57cda6742025373).
-This estimate can be adjusted for fewer/more students, running the VMs shorter/longer and adding additional services if desired.
+The total depends on attendee count, runtime, and which optional environments are deployed. Smaller charges also apply for services such as Key Vault, ACI, and ACR.
+An Azure Pricing Calculator estimate is available [here](https://azure.com/e/1a7aec76a3e049cba57cda6742025373) and should be adjusted for the current challenge design, attendee count, and runtime.
 
 If you plan to run this MicroHack in your own subscription on a limited budget, you may skip deploying the prerequisites for Challenge 6, this would leave you with a cost of less than 50 USD for one day as long as resources are deleted when finished with the challenges.
 

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

@@ -1,36 +1,42 @@
-# Challenge 4 - Encryption in use with Azure Confidential Compute – VM
+# Challenge 4 - Runtime attestation with Confidential ACI
 
 [Previous Challenge](challenge-03.md) - **[Home](../Readme.md)** - [Next Challenge](challenge-05.md)
 
 ## Goal
 
-Deploy and validate guest attestation on Azure Confidential VMs to ensure business logic only executes in trusted, compliant confidential computing environments. You'll build and deploy a sample application that implements secure attestation flows using Azure Confidential VMs. The application leverages Microsoft Azure Attestation (MAA) to validate VM integrity before executing protected business logic, demonstrating "encryption in use" capabilities.
+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
 
-* Create Key Vault and SSH Keys
-* Create Attestation Provider
-* Create Virtual Network and Confidential VM
-* Create Azure Bastion
-* Configure Confidential VM (Run on the CVM)
-* Review the attestation token output
+- 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)
 
 ## Solution
 
 > [!TIP]
-> We encourage you to try solving the challenge on your own before looking at the solution. This will help you learn and understand the concepts better.
+> Try to identify which hardware evidence the application needs before opening the walkthrough.
 
 <details>
 <summary>Click here to view the solution</summary>

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

@@ -1,39 +1,40 @@
-# Challenge 5 - Encryption in use with Confidential VMs/Node Pools in Azure Kubernetes Service (AKS)
+# Challenge 5 - Confidential workloads on AKS
 
 [Previous Challenge](challenge-04.md) - **[Home](../Readme.md)** - [Next Challenge](challenge-06.md)
 
 ## Goal
 
-Deploy and validate guest attestation on Azure Confidential VMs to ensure business logic only executes in trusted, compliant confidential computing environments. You'll build and deploy a sample application that implements secure attestation flows using Confidential VMs in AKS. 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
 
-* Create an AKS Cluster
-* Add a Confidential VM Node Pool
-* Verify Node Pool Configuration
-* Run 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)
 
 ## Solution
 
 > [!TIP]
-> We encourage you to try solving the challenge on your own before looking at the solution. This will help you learn and understand the concepts better.
+> Before opening the walkthrough, decide how Kubernetes can constrain a workload to confidential nodes.
 
-<details>
-<summary>Click here to view the solution</summary>
-
-[Solution for Challenge 5](../walkthrough/challenge-05/solution-05.md)
-
-</details>
+[Automated walkthrough for Challenge 5](../walkthrough/challenge-05/solution-05.md)

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)