Terraform KeyVault and Access Policy

EPISODE 30
We will start building a DevOps infrastructure project where we'll deploy a KeyVault and SSH key that can be used by multiple applications. We'll setup a Git repository on Azure DevOps and Terraform Plan and Apply pipelines for both our DEV and PROD Azure Subscriptions. Finally, we'll learn about first-time-apply failures and how we should use the "depends_on" attribute to resolve these implicit relationships between resources.
Follow me on Twitter for quick code snippets and thoughts on Cloud, Automation and other things!
/ marktinderholt
Keep the knowledge flowing!
www.buymeacoff...
Source Code:
github.com/mar...
Azure ARM Resources Provider
registry.terra...
v3.41.0
registry.terra...
Additional Providers:
- Random Provider (registry.terra...)
Terraform Resource List:
- random_string
- azurerm_resource_group
- azurerm_storage_account
- azurerm_log_analytics_workspace
Azure Resource Naming Conventions
learn.microsof...

[@artisticcheese]

How do you effectively debug/develop when you are running under your local account locally while your code references azurerm_client_config and it's completely different account when the same code is deployed to AzDo and as a result state file keeps changing depending how you run the code

[@azure-terraformer]

Good question, you have options, IF you don't hard code your backend :) Which is why I am a firm believer that backend config should be passed in from the outside. Locally, I can either configure the backend to point at a shared dev environment or a temporary environment just for me. run my testing locally using my own identity, once i'm happy i can destroy this temporary environment and submit a PR to carry forward the changes to the real environments and real backend...

[@azure-terraformer]

Ah. I see your point now. You can't deploy to the terraform managed environments because it will change the access policy. If you notice in these AzDO pipeline episodes, I never deploy locally. I always let the pipeline run my code. If I needed to do something crazy like state manipulation, this is a break glass moment, and I'd have to break the glass by creating a new Client Secret and setting up the Terraform SP locally to really mess with the environment. This can be hard to do in very regulated environments.

[@artisticcheese]

@@azure-terraformer I keep thinking there must be a way to do it reliably locally somehow under different accounts with use of `override` files but failed to make it work so far.