When deploying to Azure whether through a CI/CD pipeline, Azure Portal, or any other supported method, there are gates we can add to help empower and support that deployment. Gem cutters must consider this question often. Should I hit it with a hammer? When gems are cut, they are carefully faceted to match an ideal solution. Obviously gems that are cut well sell for more money than the cost of the raw stone and the work put into it. When a gem cutter decides that it is not going to return that value, they hit it with a hammer and the waste scraps are put towards other uses. Azure Policy will ask you the same question, for some similar reasons, “Should I hit this deployment with a hammer?”
Regardless of the methods used for deployment, we should be equally empowered within defined boundaries. It is possible with policy to “deny,” when a deny policy effect is handled the request returns a forbidden state and is stopped in its tracks, or in simpler terms, policy whacks the deployment with a hammer. Often on a governance journey this is the first step, but is it the right step? Such denials stop development. This may be right for production, but wrong for development; right for externally facing applications, but wrong for internally accessible applications; and on and on. Dialogue is important here. Auditing deployments can be used to start that dialogue. When an audit event is triggered warnings are issued instead of denials and work can continue.
|
The audit rule snippet, when violated, allows our deployment to continue and is validated at the end of the deployment, messages are added to our audit log citing the warning on this deployment. |
The deny audit rules snippet, when violated, demands that before the deployment starts our deployment will fail with no further actions taken. |
|
“policyRule”: { “if”: { “allOf”: […] }, “then”: { “effect”: “audit” } } |
“policyRule”: { “if”: { “allOf”: […] }, “then”: { “effect”: “deny” } } |
If I am safest with denial, should I not I always deny? Probably not. There are methods and patterns in Azure policy that will allow us to remediate deployments after the fact. For instance, when resources are not properly tagged, rather than deny for a comparatively trivial missing tag, our remediation will properly tag after the fact, which keeps us moving forward as a team and keeps us moving forward with governance. Open and consistent dialogues are especially important. We are all creating that ideal Azure gemstone together, taking the time to give us effective policy facets is key to effective empowerment.
Empowering your organization in Azure within the bounds of your business goals takes time but is worth the effort for both development teams and business leaders.
If you answered yes to one or more questions you likely have self-service issues working with Azure. For more assistance or a free consultation, contact InCycle. Alternatively, to learn more about enterprise governance, download Azure Governance Playbook!