Virtual network injection in Azure Chaos Studio

Azure Virtual Network is the fundamental building block for your private network in Azure. A virtual network enables many types of Azure resources to securely communicate with each other, the internet, and on-premises networks. A virtual network is similar to a traditional network that you operate in your own datacenter. It brings other benefits of Azure's infrastructure, such as scale, availability, and isolation.

Virtual network injection allows an Azure Chaos Studio resource provider to inject containerized workloads into your virtual network so that resources without public endpoints can be accessed via a private IP address on the virtual network. After you've configured virtual network injection for a resource in a virtual network and enabled the resource as a target, you can use it in multiple experiments. An experiment can target a mix of private and nonprivate resources if the private resources are configured according to the instructions in this article.

We are also now excited to share that Chaos Studio supports running agent-based experiments using Private Endpoints! Chaos Studio now supports Private Link for both service-direct and agent-based experiments. If you would like to use Private-Link for agent-based experiments, please reach out to your CSA or visit How to: Setup private link for agent-based experiments. For private link for service-direct faults, read the following sections for instructions on how to use them.

Resource type support

Currently, you can only enable certain resource types for Chaos Studio virtual network injection:

  • Azure Kubernetes Service (AKS) targets can be enabled with virtual network injection through the Azure portal and the Azure CLI. All AKS Chaos Mesh faults can be used.
  • Azure Key Vault targets can be enabled with virtual network injection through the Azure portal and the Azure CLI. The faults that can be used with virtual network injection are Disable Certificate, Increment Certificate Version, and Update Certificate Policy.

Enable virtual network injection

To use Chaos Studio with virtual network injection, you must meet the following requirements.

  1. The Microsoft.ContainerInstance and Microsoft.Relay resource providers must be registered with your subscription.
  2. The virtual network where Chaos Studio resources will be injected must have two subnets: a container subnet and a relay subnet. A container subnet is used for the Chaos Studio containers that will be injected into your private network. A relay subnet is used to forward communication from Chaos Studio to the containers inside the private network.
    1. Both subnets need at least /28 for the size of the address space (in this case /27 is larger than /28, for example). An example is an address prefix of 10.0.0.0/28 or 10.0.0.0/24.
    2. The container subnet must be delegated to Microsoft.ContainerInstance/containerGroups.
    3. The subnets can be arbitrarily named, but we recommend ChaosStudioContainerSubnet and ChaosStudioRelaySubnet.
  3. When you enable the desired resource as a target so that you can use it in Chaos Studio experiments, the following properties must be set:
    1. Set properties.subnets.containerSubnetId to the ID for the container subnet.
    2. Set properties.subnets.relaySubnetId to the ID for the relay subnet.

If you're using the Azure portal to enable a private resource as a Chaos Studio target, Chaos Studio currently only recognizes subnets named ChaosStudioContainerSubnet and ChaosStudioRelaySubnet. If these subnets don't exist, the portal workflow can create them automatically.

If you're using the CLI, the container and relay subnets can have any name (subject to the resource naming guidelines). Specify the appropriate IDs when you enable the resource as a target.

Auto-Tagging of Experiment Resources

When a Chaos Studio experiment is configured to run with private networking enabled, Chaos Studio automatically provisions two key resources in your subscription:

  1. An Azure container instance that facilitates secure communication.
  2. An Azure relay that manages network routing for the experiment to the Chaos Studio backend.

Previously, these created on behalf of resources did not inherit the tags applied to the experiment, which could cause Azure Policy enforcement conflicts in environments that require resource tagging.

With this update, Chaos Studio now automatically applies the same tags from your experiment to the container and relay resources it creates. This improvement enhances resource visibility, compliance, and governance within your Azure environment.

How It Works

  • Pre-requisite: You are creating an experiment that targets resources that are within a virtual network.
  • When an experiment is tagged, those same tags are automatically propagated to any resources Chaos Studio provisions for private networking.
  • These tags will be visible in the Azure portal, Azure CLI, and ARM API queries, just like any other Azure resource.
  • No additional configuration is required—simply applying tags to your experiment ensures they are inherited by all related resources.

Benefits

Ensures Compliance – Resources now meet Azure Policy tagging requirements.
Improves Resource Tracking – All experiment-associated resources carry the same tags for easy identification.
No Extra Setup Required – Works automatically when an experiment is tagged.

Example: Use Chaos Studio with a private AKS cluster

This example shows how to configure a private AKS cluster to use with Chaos Studio. It assumes you already have a private AKS cluster within your Azure subscription. To create one, see Create a private Azure Kubernetes Service cluster.

  1. In the Azure portal, go to Subscriptions > Resource providers in your subscription.

  2. Register the Microsoft.ContainerInstance and Microsoft.Relay resource providers, if they aren't already registered, by selecting the provider and then selecting Register. Reregister the Microsoft.Chaos resource provider.

    Screenshot that shows how to register a resource provider.

  3. Go to Chaos Studio and select Targets. Find your desired AKS cluster and select Enable targets > Enable service-direct targets.

    Screenshot that shows how to enable targets in Chaos Studio.

  4. Select the cluster's virtual network. If the virtual network already includes subnets named ChaosStudioContainerSubnet and ChaosStudioRelaySubnet, select them. If they don't already exist, they're automatically created for you.

    Screenshot that shows how to select the virtual network and subnets.

  5. Select Review + Enable > Enable.

    Screenshot that shows how to review the target enablement.

Now you can use your private AKS cluster with Chaos Studio. To learn how to install Chaos Mesh and run the experiment, see Create a chaos experiment that uses a Chaos Mesh fault with the Azure portal.

Limitations

  • Virtual network injection is currently only possible in subscriptions/regions where Azure Container Instances and Azure Relay are available.
  • When you create a Target resource that you enable with virtual network injection, you need Microsoft.Network/virtualNetworks/subnets/write access to the virtual network. For example, if the AKS cluster is deployed to virtual network_A, then you must have permissions to create subnets in virtual network_A to enable virtual network injection for the AKS cluster.
  • If your organization has a policy requiring resource tags, this will fail when using Chaos Studio with Private Networking. You will need to disable this policy for the time being until our fix for this issue is rolled out.

Next steps

Now that you understand how virtual network injection can be achieved for Chaos Studio, you're ready to: