Description

Role-Based Access Control (RBAC) for Azure Key Vault allows you to assign specific permissions to users, groups, or service principals based on their roles, enabling more granular control over who can access and manage secrets, keys, and certificates in Azure Key Vault. Enabling RBAC provides a modern access management model for Azure resources, offering more flexibility than traditional access control models like access policies.

Rationale

Enabling RBAC for Azure Key Vault enhances security by ensuring that only authorized users and applications have access to sensitive data stored within the Key Vault. With RBAC, you can enforce the principle of least privilege, ensuring that users have only the minimum permissions they need to perform their tasks. This aligns with best practices for security and compliance standards like SOC 2, HIPAA, and GDPR, which mandate strict control over access to sensitive information.

Impact

Enabling RBAC simplifies access management and integrates with Azure Active Directory (AAD), providing centralized control over who can access Azure Key Vault resources. However, it requires proper role assignments and may impact existing access configurations, especially if access policies are already in use. RBAC is designed to complement or replace access policies and requires appropriate configuration for key vault access and permission management.

Default Value

By default, RBAC is not enabled for Azure Key Vault, and access control is managed through Access Policies. RBAC needs to be explicitly enabled for Azure Key Vault.

Pre-requisites:

  • Azure account: Ensure you have the necessary permissions to modify RBAC settings on Azure Key Vault.

  • Azure Key Vault: Ensure that an Azure Key Vault instance is already set up and accessible.

  • Permissions: You need Owner or Contributor role to enable RBAC on Azure Key Vault and to configure access controls.

Remediation:

Audit:

To check if RBAC is enabled for your Azure Key Vault:

  1. Sign in to the Azure portal using an account with appropriate permissions.

  2. Navigate to the Azure Key Vault:

    • In the Azure portal, go to Key Vaults and select the relevant Key Vault.

  3. Check RBAC Settings:

    • In the Settings section of the Key Vault, click on Access control (IAM).

    • Verify that RBAC is enabled, and ensure that appropriate roles (e.g., Key Vault ContributorKey Vault Reader, etc.) are assigned to the necessary users, groups, or service principals.

Automated Implementation:

To ensure RBAC is enabled for Azure Key Vault across all relevant Key Vaults, you can use Azure Policy.

  1. Create a custom Azure Policy to ensure RBAC is enabled:

    • Go to the Azure portal.

    • Navigate to Policy and click on Definitions.

    • Create a new Custom Policy with the following content:

{
  "properties": {
    "displayName": "Ensure Role-Based Access Control (RBAC) is Enabled for Azure Key Vault",
    "policyType": "Custom",
    "mode": "All",
    "description": "This policy ensures that Role-Based Access Control (RBAC) is enabled for Azure Key Vault.",
    "parameters": {},
    "metadata": {
      "version": "1.0.0",
      "category": "Identity"
    },
    "policyRule": {
      "if": {
        "field": "Microsoft.KeyVault/vaults/enableRbac",
        "equals": "false"
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}


  1. Assign the policy:

    • After creating the custom policy, assign it to the relevant subscriptions or resource groups to ensure that RBAC is enabled for Azure Key Vault.

Backout Plan:

To disable RBAC for Azure Key Vault:

  1. Sign in to the Azure portal with appropriate permissions.

  2. Navigate to the Azure Key Vault:

    • In the Azure portal, go to Key Vaults and select the relevant Key Vault.

  3. Go to Access Control (IAM):

    • In the Settings section, click on Access control (IAM).

  4. Disable RBAC:

    • Change the RBAC setting to Disabled. This will revert the access control management back to Access Policies.

If the setting was enforced via Azure Policy, modify or remove the policy to allow access control through access policies again.

References: