You gave better explanation of storage account settings then some of azure content creators. Thank you for the video.

Great vid, as usual :) I recommend using user-assigned managed identities, rather than Entra SPNs. Reasons are twofold: Firstly, it's an ARM resource so much easier to manage admin access and RBAC (the Entra permissions model is horrible). Secondly, UMIs work with both cloud-based ci/cd (using federation & OIDC) AND they work with self-hosted ci/cd as they can be assigned to the resource as a managed identity 😀

Thanks for this, you've given me a good path. I'm not an Azure guy and I'm trying to secure state access while using Azure DevOps. Currently using the storage key as a secret but I would rather use another method with private endpoints.

Do you have a video on using Azure Storage for TFstate and running a pipeline using Azure DevOps, but using App Registration for running the pipeline - would love to know your recommendations for best practices

@NedintheCloud

5 ай бұрын

Not yet, but I like the idea!

Very good explanation on how to store and secure a tfstate on an azurerm. I even learnt the access conditions which is very powerful. I never came across a real use-case. One feedback on the GRS replication. With GRS the tfstate will be replicated to the pair region, but you will rely on the microsoft support team to failover the master nodes of the storage accounts before you can access the tfstate on the other region. Most of the time this is to respond to a datacenter or availability zone failure. and it could take some hours in some circumstances. To mitigate that I would recommend RAGZRS when possible (or RAGRS) (1- ZRS means your state got replicated in all availability zones in the region, meaning you can mitigate an AZ failure, 2- G replicate to the pair region, 3- RA will keep the replica on the paired region readable, meaning you don't have to wait to access the tfstate if needed.)

Do that OIDC! Oh, also... instead of Entra ID service principals... Managed Identities... no need to talk with the Graph API with the AzureAD provider... one provider, one API, good practices!

Banger of a vid as usual, Ned! Question: Wouldn’t service endpoint be a better choice for Azure-hosted worker nodes? Privatelink is expensive. Service endpoint is free.

@NedintheCloud

5 ай бұрын

Depends on your requirements. Private link keeps the traffic off the public network side. Service endpoint still uses the public endpoint of the storage account, but restricts traffic.

Great content as always, please explain a scenario that covers the provision of blob behind a private endpoint along with a Linux VM agent for Azure DevOps that has access to the blob, the agent will be used for running the terraform pipeline while having access to the backend for state file. I did set the agent with an extension for vm but wondering if there is a clear terraform solution for the ADO self-host agents? Thanks again Ned.

I absolutely love these videos. There's always something new I can use to make my TF code better. Do you think you can make a video on how to have a VM join an on-premise domain (not Azure AD) with TF code? I haven't found a way to do that yet.

@NedintheCloud

3 ай бұрын

Depends on the platform you are deploying to. You can use a provisioner, but it's better to use a startup script of some kind.

@valp8198

3 ай бұрын

@NedintheCloud thanks. I found that using an extension works best for my windows VMs. For Linux that's been another issue though.

Good one! How do you handle the backend code repository? I mean do you create a repository just for the storage account?

@NedintheCloud

2 ай бұрын

That's a super tough one. I've seen three basic approaches: 1. Use a managed service that provides a state backend for you 2. Create the azure storage account in the same config and then update the backend block to use the storage account you just created (aka inception) 3. Have a dedicated repository and workspace that provisions storage accounts for other deployments

Generate sas token. My wish list.