Locking a stack against changes through other channels than IaC

[henrybeen]

With deployment stacks as a self-deployed, strong grouping around resources, it would be great to also protect these resources from change/deletion through other channels than manipulation through IasC.

This way you can force deletes and updates to the resources to also come from manipulationg the stack, by deploying a new template.

Especially in organizations that are still at a mix of IaC and manually managed resources, this can enforce the right practice for IaC-managed resources.

Maybe a property: protectFromOutsideChange (bool), that enables this type of protection on a stack?

[snarkywolverine]

If you are familiar with Blueprints, we are planning to implement functionality similar to what Blueprints has:

https://docs.microsoft.com/en-us/azure/governance/blueprints/concepts/resource-locking

Would that address your scenarios?

[henrybeen]

I'm familair with Blueprints, and I know that this is planned. (Great!)

But blueprints will lock a stack against change by those who are authorized on the individual resource, but wouldn't it be interesting to lock against change from anything, but IaC? Just to enforce change through IaC over manual?

[bmoore-msft]

@henrybeen - you mean something like "this resource can only be updated by updating the stack itself"? You could do that by using a read-only lock and no excepted principals... though the owner could delete the stack, update the resources and re-apply the stack (but that's true of any "protection" you try to use).

This is not really a stacks scenario but we've been looking at ways to say "block edits via portal or powershell". They aren't perfect but it's a lot close to what people really want when they are trying to protect something. Is that inline with your scenario?

[henrybeen]

Your last statement, 'block edits via portal, ps, cli, rest' (anything not iac) is what I'd be looking for. I don't know if stacks are the right place for that, but it's something I've been finding myself to want at some points.

The scenario is then a team that started doing manual infra deploys and needs to migrate to iac and half-way that migration it can be messy what is done through iac and what not. A setting like this can then be used to enforce the new practice wherever it applies.

[bmoore-msft]

@henrybeen - we've been working through the scenarios for denySettings (formerly known as "locks") and the way everything is working out you'd be able to emulate this scenario with denySettings: denyWrite. When used, only the stack that created the resource would be able to update it.

It sounds like that gets to what you're after - any issues you can see with it?

[henrybeen]

I'm very busy catching up on "all things that message me," so I still have to dive into denySettings, but what I think to read between the lines is that this would deny writing to the resources directly (achieving what I want), and enforce any change to go through the stack.

Is that correct?

[bmoore-msft]

Yep - and you could still "exclude" certain principles and/or actions as well... so for example you could still allow startup/shutdown of a vm if needed.

[nbwdk]

Any update on this implementation. I really want to test this out. This implementation is the main reason we are still using blueprints to baseline landing zones.

[bmoore-msft]

You can see a bit about the next preview here: https://youtu.be/tPrpsKVEhSU?t=225 - we're going through a deployment and final testing now.

[azcloudfarmer]

The latest release of Stacks addresses this issue with the DenyWriteAndDelete capability.