Create resource "policy" hooks in New-TestResources script
- Dominant language
- C#
- Stars
- 135
- Forks
- 260
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 143
Description
There are several cases across our test pipelines where we end up with "sticky" resources, such as soft-deleted keyvaults and/or managed HSMs. These can be pretty expensive, and persist long after our resource group deletion scripts. By default, resources like this can stick around for 30-90 days incurring cost.
There are a few ways that this problem can be addressed that have been discussed to date:
1. Update all live test ARM templates to add shorter retention policies
2. Update all relevant live tests across the languages to perform custom deletions
3. Update our cleanup scripts to inspect resource group contents, and perform custom actions (e.g. purge keyvault, delete immutable storage container).
There is already work for items 2 and 3, but I think it might be a useful mechanism in general to be able to define and inject global ARM template policies for deployments that go through our scripts. For example, this could look like the following:
- Deploy template script is called
- Template contains a resource covered by a policy
- Policy contains an incremental ARM template snippet specifying a 24 hour retention policy for managed HSM
- Template does not already specify an HSM retention policy, and would otherwise use the default
- Merge the template with the policy template
- Deploy updated template
Another possible direction, which would require less custom json handling work, is to migrate templates we want to govern via policy to use [bicep](https://github.com/Azure/bicep), and have a common bicep modules available to each repo that should be included for various resource types.
I could see this being useful in many other cases where we determine that specific configurations for resources have a great impact on cost and no impact on test functionality. Having a policy mechanism would make it easy to enact these changes.
CC @heaths @weshaggard
Contributor guide
Assessment
This issue has not been assessed yet.