Azure News - 2026-05-09

The Root Cause: Index-Based "for_each" Keys:

Many Terraform modules flatten VM and disk definitions into a list and use the list index as the for_each key:

for_each = { for index, sp in local.managed_disks : index => sp }

This pattern looks harmless, but the index is not stable:

• Adding a disk to one VM shifts downstream indices
• Reordering environment JSON changes flatten order
• Terraform treats shifted indices as new resources

The result: Terraform plans to destroy and recreate all affected managed disks—even though nothing changed in Azure.

Why This Is Especially Risky on Azure:

Azure managed disks are often:

• Attached to stateful application tiers
• Used for databases, middleware, or batch workloads
• Deployed across zones for resiliency

A forced disk replacement can mean:

• Data loss
• Extended outages
• Failed change windows

This makes state stability a first-class design concern—not an implementation detail.

The Stable Key Pattern:

The fix is conceptually simple: use a domain-stable identifier for each disk.

A proven pattern is:

"${sp.vm}-${sp.data_disk.lun}"

This key is:

• Deterministic
• Independent of ordering
• Human-readable
• Stable across environments

Example:

Once applied, adding a new disk results in exactly one new resource, with zero churn.

The Migration Challenge: Terraform State:

Changing for_each keys alone is not enough.

Terraform tracks resources by their state address, not by Azure resource ID. When keys change, Terraform believes:

“The old disks were deleted, and new ones must be created.”

To prevent this, we must move the state, not recreate the resource.

That is where terraform state mv comes in.

Automating the Migration with GitHub Copilot Skills:

To remove risk and human error, the team created a reusable Copilot skill for managed disk key migration.

What the Skill Does:

• Inspects Terraform modules for index-based for_each
• Reads environment JSON files (such as ALZ variable abstractions)
• Reconstructs the exact flatten order used by Terraform
• Generates precise terraform state mv commands

This ensures:

• No guessing
• No manual address mapping
• No production surprises

The skill is stored directly inside the repository under .github/skills, making it:

• Discoverable
• Versioned
• Shareable across teams

Example: Generating State Move Commands:

Based on environment JSON, Copilot can generate commands like:

terraform state mv \

  'module.managed_disk_windowsvm_app["0"]' \

  'module.managed_disk_windowsvm_app["vm1-0"]'

This is repeated deterministically for every existing disk—before any plan or apply.

Recommended Migration Workflow:

1. Confirm clean state

   • terraform plan shows no pending changes

2. Update the module

   • Replace index-based keys with stable keys

3. Back up the state

   • Especially critical with remote backends (Azure Storage)

4. Run terraform state mv

   • Only after terraform init is connected to the correct backend

5. Re-run plan

   • Existing disks should show no changes

6. Add new disks safely

   • Terraform creates only the new disk

CI/CD and Remote Backend Considerations:

A critical finding from this migration:

terraform state mv always modifies the currently initialized backend.

In pipeline-driven environments:

• Ensure the correct environment is initialized
• Run migrations once per environment
• Never merge stable-key code before migrating all environments

Failing to align code and state can cause disk destruction in production.

Key Takeaways:

• Index-based for_each keys are unsafe for long-lived Azure disks
• Stable keys such as vm-lun eliminate accidental resource churn
• State migration is mandatory—not optional
• Copilot skills are powerful for institutionalizing safe patterns
• Small Terraform design choices can have enterprise-scale impact

Closing Thoughts:

This pattern is broadly applicable beyond disks—to NICs, extensions, and any resource where identity must outlive ordering.

By combining:

• Stable Terraform design

• State-aware migrations

• GitHub Copilot automation

Teams can make infrastructure changes boring again—and that is the ultimate reliability goal.

Memory safety vulnerabilities—largely arising from widely used programming languages such as C and C++—remain a leading cause of exploitable software defects across systems, from embedded devices to cloud-scale infrastructure. In simple terms, memory safety ensures that software accesses only the data it is intended to use; when this protection fails, attackers can exploit these defects to gain control of devices or disrupt critical services.  

Industry data shows that about 70 percent of the vulnerabilities Microsoft assigns as Common Vulnerabilities and Exposures (CVE) each year are memory safety issues, highlighting how frequently these software defects translate into real-world security risk (CISA – The Urgent Need for Memory Safety in Software Products). Hardware-enforced protections such as CHERIoT-Ibex can help eliminate these vulnerabilities at their source, reducing the likelihood that low-level software flaws can be exploited to compromise devices or disrupt workloads, supporting more trustworthy infrastructure by design.  
 
An open and certified foundation for memory-safe embedded systems 

CHERIoT-Ibex is the first open-source production-quality implementation of the CHERIoT instruction set architecture and among the first cores certified by the CHERI Alliance (CHERI Alliance – CHERIoT). CHERIoT is an extension of the CHERI (Capability Hardware Enhanced RISC Instructions) instruction set, with a focus on embedded and Internet of Things (IoT) applications. Ibex is an open‑source 32‑bit RISC‑V core developed by LowRISC. CHERIoT‑Ibex builds on Ibex by including CHERIoT capability extensions to provide hardware‑enforced memory safety and fine‑grained compartmentalization. It is the result of a close partnership between Microsoft Research and Azure Hardware Systems & Infrastructure, combining advanced research innovation with industry-leading silicon IP development expertise.  

In 2023, Microsoft open-sourced the CHERIoT Platform to bring hardware-enforced memory safety to embedded systems, including an instruction set architecture, toolchain, real-time operating system, and the RTL implementation of the CHERIoT-Ibex core. The CHERI Alliance certification recognizes its ability to provide spatial and temporal memory safety, fine-grained compartmentalization, and compatibility with the broader CHERI ecosystem. Critically, CHERIoT-Ibex achieves these security guarantees with power and area efficiency comparable to low-cost microcontrollers, demonstrating that security doesn’t have to come at a premium.  
 

Why memory safety remains a foundational security challenge 

Traditional embedded and microcontroller-class designs rely on software hardening and coarse-grained hardware protections that struggle to prevent attacks such as buffer overflows and use-after-free vulnerabilities, often adding complexity while still leaving gaps in protection.  

Consider a controller that runs privileged firmware responsible for device initialization, telemetry, and system health monitoring, while also hosting networking functionality exposed to external inputs. A memory-safe vulnerability in the networking stack could allow attackers to execute unauthorized code within the firmware environment, potentially affecting other critical services on the device. In tightly integrated systems, these failures can propagate beyond a single component, increasing overall risk. 

 
Constraining failures with hardware-enforced isolation 

CHERIoT-Ibex enables hardware-enforced isolation between these components, helping ensure that even if the networking stack is compromised, its ability to impact system initialization or telemetry functions remains constrained. By limiting the blast radius of software failures, CHERIoT-Ibex supports a system-level approach to security rather than relying on individual components to defend themselves in isolation. 

 
Advancing memory-safe infrastructure by design 

CHERIoT-Ibex’s certification by the CHERI Alliance marks an important milestone for open-source memory-safe solutions. It validates that strong security guarantees can coexist with efficiency and transparency, reflecting Microsoft’s broader silicon-to-systems strategy of embedding security into the foundational hardware infrastructure. 

Explore and engage with the open-source CHERIoT ecosystem by visiting the CHERIoT Platform and the CHERIoT-Ibex GitHub repository (microsoft/cheriot-ibex). The repositories enable developers and researchers to experiment with, contribute to, and build on memory-safe hardware and software foundations.