[Policy]: Encryption at Host resources still marked as unhealthy

[brotheroneill]

Policy Definition or Initiative

Definition

Built-in/Custom

Built-in

Built-in policy definition or initiative ID

/providers/Microsoft.Authorization/policyDefinitions/0961003e-5a0a-4549-abde-af6a37f2724d

Custom policy definition or initiative description

A policy that does ...

Scope

Intermediate Root

Default Assignment

• [ ] Yes

Comments/thoughts

The policy 0961003e-5a0a-4549-abde-af6a37f2724d for "Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources" only detects Azure Disk Encryption. However, Encryption at Host (at least my understanding) meets the requirment of the policy as it encrypts temp disks, caches and data between compute and storage. I've been recommended to switch from using this policy, with two others that detect both ADE and EAH, the policies are: /providers/Microsoft.Authorization/policyDefinitions/3dc5edcd-002d-444c-b216-e123bbfa37c0 /providers/Microsoft.Authorization/policyDefinitions/ca88aadc-6e2b-416c-9de2-5a0f01d1693f

Both policies are marked as being in preview and therefore I'm not sure on their suitability as a direct replacement yet until they become GA. I'm raising this here as the policy 0961003e-5a0a-4549-abde-af6a37f2724d appears in at least one initiative within this repo, and also in the ALZ Bicep repo which we consume. I suspect it appears in multiple initiatives/policy sets, though the example I've found is: /providers/Microsoft.Authorization/policySetDefinitions/1f3afdf9-d0c9-4c3d-847f-89da613e70a8

[Springstone]

Hi @brotheroneill! Thanks for reaching out! For the policy you're referring to "Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources", if you read the description of the policy, it answers part of your question:

"By default, a virtual machine's OS and data disks are encrypted-at-rest using platform-managed keys. Temp disks, data caches and data flowing between compute and storage aren't encrypted. Disregard this recommendation if: 1. using encryption-at-host, or 2. server-side encryption on Managed Disks meets your security requirements. Learn more in: Server-side encryption of Azure Disk Storage: https://aka.ms/disksse, Different disk encryption offerings: https://aka.ms/diskencryptioncomparison"

The two new policies that do detect EAH are for Windows and Linux respectively. For your purposes I'd switch to using those, don't worry too much about them being in preview. All new policies initially launch with the preview classification, but product groups generally do thorough testing on policies before they get published.

Note however, these are built-in policies (you can tell because the name is a GUID). We do not maintain built-in policies, those are provided by the respective product groups. We do provide best practice initiatives and custom policies that we maintain, and we can consider adding those two new policies to our respective initiative if it aligns with our overall (for everyone) best practice guidance. To get support on built-in policies your best avenue is a support ticket in Azure.

[brotheroneill]

Hi @Springstone, thanks for such a prompt response. I knew we could disregard/exempt resources from the policy, but it felt like we weren't really addressing the problem, hence raising it here. My concern was that we become complacent with the recommendation, and one day miss a genuine issue because we assume "that policy is old, it's always a false positive because we're using EAH".

I guess I'm thinking that my organisation and I can't be the only customers having this challenge with this policy, and because we're assigning this policy as part of a policy set within this repo, it felt appropriate to raise it here to see if something needs to be done centrally within that policy set, i.e. swap the policy in question out for the two recommended.

[Springstone]

Hi @brotheroneill. Many thanks for the quick reply. You are 100% correct, and as you kind of highlight it is a bit of a balancing act. Most customers aren't using EAH yet, or have various combinations that make it difficult to make everyone happy. At some point, you will always end up with "non-compliant" policies (even if part of an initiative) because you may have made some different choices. In this case, we could add the two new policies, but that doesn't change that the original one will always be non-compliant for you.

I'll add it to our backlog to be included in our initiative, but in the meantime, you could delete our default assignment, edit the initiative (it is a custom) to remove the old policy and include the new ones, and re-assign. You should be in a good state then (green :))

Let me know if this makes sense, or if you have any additional thoughts.

[brotheroneill]

We're on a roll! :) that's fair, perhaps I was being naïve but I was thinking that the two proposed policies mean irrespective of what method you're using, everyone is happy.

We're consuming the policy set via the ALZ-Bicep repo, specifically within infra-as-code\bicep\modules\policy\assignments\alzDefaults\alzDefaultPolicyAssignments.bicep. There's guidance here on how to exclude specific policy if it doesn't fit your organisations needs, but because this is included as part of a policy set, if we exclude it we're disabling a whole stack of policy.

If it's on the backlog I guess we'll just sit tight until it's look at.

[Springstone]

@brotheroneill you are not wrong. The two policies do cover all scenarios, however, with a caveat being that guest configuration is deployed and configured properly, and this is rarely the case (https://aka.ms/gcpol). All of that with firewall rules, etc needs to be in place, with additional configurations required when using private endpoints (link), it's not trivial. We do need to make careful considerations in what we propose for all customers that use ALZ.

All the reference implementations (including ALZ-Bicep) use the policies and initiatives from this repo, btw, so you raised your issue in the right place.

Again, don't sit tight. Don't exclude either. Modify our custom initiative, remove the original policy and add the two previews, if this meets your requirements. You will need to delete the original assignment, and re-assign the updated initiative, but this should address your immediate requirement.

Let us know if this works. There is no silver bullet that works for everyone unfortunately, hopefully this helps you achieve your objectives.