Feature Request - Less strict assignment of guardrails for Azure Key Vault

[prutsert]

According to the documentation, the "Enforce recommended guardrails for Azure Key Vault" assignment is done according to the following description:

This policy initiative enforces minimum guardrails for Azure Key Vault:

• Key vaults should have soft delete enabled (Deny)
• Key vaults should have purge protection enabled (Deny)
• Key Vault secrets should have an expiration date (Audit)
• Key Vault keys should have an expiration date (Audit)
• Azure Key Vault should have firewall enabled (Audit)
• Certificates should have the specified lifetime action triggers (Audit)
• Keys should have more than the specified number of days before expiration (Audit < 90 days)
• Secrets should have more than the specified number of days before expiration (Audit < 90 days)

The actual assignment, however, has many more parameters, some of which are much stricter than the list above would suggest. Examples include:

• Certificates should not expire within the specified number of days (Deny)
• Secrets should have content type set (Deny)
• Certificates should use allowed key types (Deny)
• Certificates should be issued by the specified integrated certificate authority (Deny)
• Secrets should have the specified maximum validity period (Deny) (will enforce a maximum validity of 90 days)

My personal opinion is that some of these Deny assignments are too strict, and should default to Audit. But even if they are appropriate for ALZ principles, they should be explicitly documented to be able to assess the impact.

[jtracey93]

Hey @prutsert, thanks for the feedback - you can always change the assignment enforcement mode to DoNotEnforce to flick it to an "audit" style initiaitve first and then review it from there and slowly work to moving back to an enforced mode.

You can also use overrides to override some the the defaults if there are not paramterized https://learn.microsoft.com/en-us/azure/governance/policy/concepts/assignment-structure#overrides

[Springstone]

@prutsert @jtracey93 the defaults being used are those defined by the product group and are best practice recommendations. I appreciate that this may not be ideal for all customers, and it is possible to amend/adjust parameters based on your needs, either specifying parameters or using overrides (depending on how you are deploying/maintaining ALZ) as mentioned by @jtracey93.

Happy to hear your feedback.

[prutsert]

Hi @jtracey93, @Springstone, thanks for your feedback. I agree, if the best practice is to set the Key Vault guardrail parameters as strict as they are now, then that's the way they should be implemented by default. There are plenty of ways to adjust either the effect or the parameters.

My point is more about the mismatch between that reality, and what the documentation reflects. The documentation suggests that there are two "Deny" effects on two no-brainers (soft delete and purge protection), and "Audit" for all the rest. That's not what it literary says, but leaving a few of the stricter effects out of the documentation makes it land between my ears like that. Of course, that a totally subjective way of reading the docs, so feel free to close this issue if you think the docs are reflecting the reality.