Microsoft Azure has a concept of virtual networks. A virtual network allocates a block of IPv4 addresses inside the network and allows for adding network security groups around it.
When more than one virtual network is defined, the secure way to connect an Azure Storage Accounts is to use a virtual network peering. The virtual network peering must be pointing to the virtual network where the storage account clients, or users, are.
A good design pattern design different components in a system as different pulumi stacks. Then, when the last pulumi stack is created (with pulumi up). If one storage account is shared across multiple virtual networks, one would update the existing virtual network with a peering between an Azure Storage account and a virtual network in different stack. Existing storage account must be updated.
In my use case I this design is used to create a new Azure Kubernetes Service (AKS), perform a backup from an old AKS, and restore the backup into the new AKS.
The similar visual representation in Microsoft Azure looks like the screenshot below
The way storage account network are set up with pulumi is based around NetworkRuleSet. By clever work on the class design by the pulumi team one can only affect a storage account network when both classes NetworkRuleSet and Pulumi.AzureNative.Storage.Inputs.NetworkRuleSetArgs exists in the same context and stack.
Microsoft Azure has a concept of virtual networks. A virtual network allocates a block of IPv4 addresses inside the network and allows for adding network security groups around it. When more than one virtual network is defined, the secure way to connect an Azure Storage Accounts is to use a virtual network peering. The virtual network peering must be pointing to the virtual network where the storage account clients, or users, are.
A good design pattern design different components in a system as different pulumi stacks. Then, when the last pulumi stack is created (with
pulumi up
). If one storage account is shared across multiple virtual networks, one would update the existing virtual network with a peering between an Azure Storage account and a virtual network in different stack. Existing storage account must be updated.In my use case I this design is used to create a new Azure Kubernetes Service (AKS), perform a backup from an old AKS, and restore the backup into the new AKS.
The similar visual representation in Microsoft Azure looks like the screenshot below
Affected feature
Affected pulumi azure native classes are
The way storage account network are set up with pulumi is based around NetworkRuleSet. By clever work on the class design by the pulumi team one can only affect a storage account network when both classes NetworkRuleSet and Pulumi.AzureNative.Storage.Inputs.NetworkRuleSetArgs exists in the same context and stack.