Overview

Hello! In today’s post, we are going to talk about how we can implement governance and compliance for a very important resource in Azure which is Azure KeyVault.

If you want to learn what is KeyVault, you can read more about it here

Now, we all know storing secrets and certificates in KeyVault is considered a best practice when it comes to storing and accessing sensitive information in Azure. And in order to follow this practice, multiple teams in an organization start storing the secrets/keys in the vault without following any standards and regulations. The management of those secrets becomes harder when we have bunch of those secrets in the vault and we are not sure if some of these are let’s say bound to expire, or some of the certificates are from unknown authorities.

Hence in order to make lives easier for Cloud Architects out there, Azure has enabled the integration between Azure Policy and Azure Keyvault. Azure policy, if you are not aware, is a governance tool used to implement guardrails for Azure resources. These policies make sure you or your teammates only deploy the approved resources with approved sizes and follow the defined best practices in the policy. You can read more about Azure policy here

Let’s dig a little deeper

In this case, Azure policy has two effects - Audit or Deny.

Audit - When the effect of a policy is set to audit, the policy will not cause any breaking changes to your environment. It will only alert you to components such as certificates that do not comply with the policy definitions within a specified scope, by marking these components as non-compliant in the policy compliance dashboard. Audit is default if no policy effect is selected.

Deny: When the effect of a policy is set to deny, the policy will block the creation of new components such as certificates as well as block new versions of existing components that do not comply with the policy definition. Existing non-compliant resources within a key vault are not affected. The ‘audit’ capabilities will continue to operate.

So you know what kind of control you can implement. Now let’s see on which components we can implement these regulations. Azure Policy definitions are available for each of the data component of KeyVault which are Keys, Secrets & Certificates, also you get some built-in definitions for management level governance control. Let’s see some of the examples of sample policies available already for you in the portal-

1. Keys, Secrets & Certificates should have expiration date set
2. Secrets should have content-type set.
3. Certificates should be issued by the specified integrated certificate authority
4. Certificates using RSA cryptography Manage minimum key size for RSA certificates
5. Keys should not be active for longer than the specified number of days
6. Key Vault should use a virtual network service endpoint
7. Resource logs in Key Vault should be enabled
8. Key vaults should have purge protection enabled

You can make use of these built-in policies in two ways. Either you can set the effect to Audit, in which case you will check the compliance status of the components and Vaults or you can set the effect to deny in which the developer will not be able to create the resource (be it data component or KeyVault itself) in the first place. Hence you can establish some sort of governance and standard practice in your Cloud KeyVault deployment. The compliance checker at the backend run every 24 hours and will populate the dashboard with the results for all the KeyVaults under the assigned scope.

Logging

In case you want to check how policy evaluations are conducted, you can enable KeyVault logging to a storage account and from there check the logs. The sample log where the policy looks for all non-compliant keys with no expiration dates are flagged-

{
      "ObjectName": "example",
      "ObjectType": "Key",
      "IsComplianceCheck": false,
      "EvaluationDetails": [
        {
          "AssignmentId": "<subscription ID>",
          "AssignmentDisplayName": "[Preview]: Key Vault keys should have an expiration date",
          "DefinitionId": "<definition ID>",
          "DefinitionDisplayName": "[Preview]: Key Vault keys should have an expiration date",
          "Outcome": "NonCompliant",
          "ExpressionEvaluationDetails": [
            {
              "Result": "True",
              "Expression": "type",
              "ExpressionKind": "Field",
              "ExpressionValue": "Microsoft.KeyVault.Data/vaults/keys",
              "TargetValue": "Microsoft.KeyVault.Data/vaults/keys",
              "Operator": "Equals"
            },
            {
              "Result": "True",
              "Expression": "Microsoft.KeyVault.Data/vaults/keys/attributes.expiresOn",
              "ExpressionKind": "Field",
              "ExpressionValue": "******",
              "TargetValue": "False",
              "Operator": "Exists"
            }
          ]
        }
      ]
    }

Limitations

Assigning a policy with a “deny” effect may take up to 30 mins (average case) and 1 hour (worst case) to start denying the creation of non-compliant resources. The delay refers to following scenarios -

• A new policy is assigned
• An existing policy assignment is modified
• A new KeyVault (resource) is created in a scope with existing policies.
• The policy evaluation of existing components in a vault may take up to 1 hour (average case) and 2 hours (worst case) before compliance results are viewable in the portal UI. If the compliance results show up as “Not Started” it may be due to the following reasons:

1. The policy valuation has not completed yet. Initial evaluation latency can take up to 2 hours in the worst-case scenario.
2. There are no key vaults in the scope of the policy assignment.
3. There are no key vaults with certificates within the scope of the policy assignment.

Note: Secrets created via ARM template would not be evaluated immediately during creation. For such secrets, the compliance check that run every 24 hours will show the status of those secrets whether or not the secrets are following the practices defined in the policy.

This feature recently became generally available so that means you can start implementing it for your production KeyVaults and become a smart Cloud consumer. This was it. Hope you find the article helpful.

• KeyVault
• Azure
• Security
• Governance
• Azure Policy