Protecting Your Azure Key Vault: Why Azure RBAC Is Critical for Security
Introduction In today’s cloud-centric landscape, misconfigured access controls remain one of the most critical weaknesses in the cyber kill chain. When access policies are overly permissive, they create opportunities for adversaries to gain unauthorized access to sensitive secrets, keys, and certificates. These credentials can be leveraged for lateral movement, privilege escalation, and establishing persistent footholds across cloud environments. A compromised Azure Key Vault doesn’t just expose isolated assets it can act as a pivot point to breach broader Azure resources, potentially leading to widespread security incidents, data exfiltration, and regulatory compliance failures. Without granular permissioning and centralized access governance, organizations face elevated risks of supply chain compromise, ransomware propagation, and significant operational disruption. The Role of Azure Key Vault in Security Azure Key Vault plays a crucial role in securely storing and managing sensitive information, making it a prime target for attackers. Effective access control is essential to prevent unauthorized access, maintain compliance, and ensure operational efficiency. Historically, Azure Key Vault used Access Policies for managing permissions. However, Azure Role-Based Access Control (RBAC) has emerged as the recommended and more secure approach. RBAC provides granular permissions, centralized management, and improved security, significantly reducing risks associated with misconfigurations and privilege misuse. In this blog, we’ll highlight the security risks of a misconfigured key vault, explain why RBAC is superior to legacy Access Policies and provide RBAC best practices, and how to migrate from access policies to RBAC. Security Risks of Misconfigured Azure Key Vault Access Overexposed Key Vaults create significant security vulnerabilities, including: Unauthorized access to API tokens, database credentials, and encryption keys. Compromise of dependent Azure services such as Virtual Machines, App Services, Storage Accounts, and Azure SQL databases. Privilege escalation via managed identity tokens, enabling further attacks within your environment. Indirect permission inheritance through Azure AD (AAD) group memberships, making it harder to track and control access. Nested AAD group access, which increases the risk of unintended privilege propagation and complicates auditing and governance. Consider this real-world example of the risks posed by overly permissive access policies: A global fintech company suffered a severe breach due to an overly permissive Key Vault configuration, including public network access and excessive permissions via legacy access policies. Attackers accessed sensitive Azure SQL databases, achieved lateral movement across resources, and escalated privileges using embedded tokens. The critical lesson: protect Key Vaults using strict RBAC permissions, network restrictions, and continuous security monitoring. Why Azure RBAC is Superior to Legacy Access Policies Azure RBAC enables centralized, scalable, and auditable access management. It integrates with Microsoft Entra, supports hierarchical role assignments, and works seamlessly with advanced security controls like Conditional Access and Defender for Cloud. Access Policies, on the other hand, were designed for simpler, resource-specific use cases and lack the flexibility and control required for modern cloud environments. For a deeper comparison, see Azure RBAC vs. access policies. Best Practices for Implementing Azure RBAC with Azure Key Vault To effectively secure your Key Vault, follow these RBAC best practices: Use Managed Identities: Eliminate secrets by authenticating applications through Microsoft Entra. Enforce Least Privilege: Precisely control permissions, granting each user or application only minimal required access. Centralize and Scale Role Management: Assign roles at subscription or resource group levels to reduce complexity and improve manageability. Leverage Privileged Identity Management (PIM): Implement just-in-time, temporary access for high-privilege roles. Regularly Audit Permissions: Periodically review and prune RBAC role assignments. Detailed Microsoft Entra logging enhances auditability and simplifies compliance reporting. Integrate Security Controls: Strengthen RBAC by integrating with Microsoft Entra Conditional Access, Defender for Cloud, and Azure Policy. For more on the Azure RBAC features specific to AKV, see the Azure Key Vault RBAC Guide. For a comprehensive security checklist, see Secure your Azure Key Vault. Migrating from Access Policies to RBAC To transition your Key Vault from legacy access policies to RBAC, follow these steps: Prepare: Confirm you have the necessary administrative permissions and gather an inventory of applications and users accessing the vault. Conduct inventory: Document all current access policies, including the specific permissions granted to each identity. Assign RBAC Roles: Map each identity to an appropriate RBAC role (e.g., Reader, Contributor, Administrator) based on the principle of least privilege. Enable RBAC: Switch the Key Vault to the RBAC authorization model. Validate: Test all application and user access paths to ensure nothing is inadvertently broken. Monitor: Implement monitoring and alerting to detect and respond to access issues or misconfigurations. For detailed, step-by-step instructions—including examples in CLI and PowerShell—see Migrate from access policies to RBAC. Conclusion Now is the time to modernize access control strategies. Adopting Role-Based Access Control (RBAC) not only eliminates configuration drift and overly broad permissions but also enhances operational efficiency and strengthens your defense against evolving threat landscapes. Transitioning to RBAC is a proactive step toward building a resilient and future-ready security framework for your Azure environment. Overexposed Azure Key Vaults aren’t just isolated risks — they act as breach multipliers. Treat them as Tier-0 assets, on par with domain controllers and enterprise credential stores. Protecting them requires the same level of rigor and strategic prioritization. By enforcing network segmentation, applying least-privilege access through RBAC, and integrating continuous monitoring, organizations can dramatically reduce the blast radius of a potential compromise and ensure stronger containment in the face of advanced threats. Want to learn more? Explore Microsoft's RBAC Documentation for additional details.
Compliance for Exposed Secrets Discovered by DevOps Security in Defender for Cloud
Compliance for Exposed Secrets Discovered by DevOps Security in Defender for Cloud Azure Policy helps enforce organizational standards and assess compliance at-scale. You can now create a custom Azure Policy to add DevOps security to your centralized compliance dashboards. This blog walks through creating a custom Azure Policy that leverages the DevOps security recommendations in Defender for Cloud called “Azure DevOps repositories should have secret scanning findings should be resolved", "GitHub repositories should have secret scanning findings resolved", and "GitLab projects should have secret scanning findings resolved". This policy gives Security and Compliance Teams visibility into discovered secrets found in Azure DevOps, GitHub, and GitLab that have been onboarded to Microsoft Defender for Cloud. Objectives: Create a custom AuditIfNotExist Azure Policy Visualize the custom policy in the Compliance view in Azure Policy Prerequisites: Connector provisioned in Defender for Cloud to your Source Code Management System (such as Azure DevOps, GitHub, or GitLab) For Azure DevOps: enable secret scanning in GitHub Advanced Security for Azure DevOps For GitHub: enable secret scanning in GitHub Advanced Security For GitLab: enable secret scanning in GitLab Ultimate Create a Custom Azure Compliance Policy for Exposed Secrets Navigate to Azure Policy Click Definitions Click + Policy definition For Definition location, choose a subscription or management group For Name, type code repositories should have secret scanning findings resolved Type a Description, such as: DevOps security in Defender for Cloud has found a secret in code repositories. This should be remediated immediately to prevent a security breach. For Category, click Create new, then type DevOps Security For Policy Rule, cut and paste the following JSON: { "parameters": { "effect": { "type": "String", "metadata": { "displayName": "Effect", "description": "Enable or disable the execution of the policy" }, "allowedValues": [ "AuditIfNotExists", "Disabled" ], "defaultValue": "AuditIfNotExists" } }, "policyRule": { "if": { "field": "type", "in": [ "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" ] }, "then": { "effect": "[parameters('effect')]", "details": { "type": "Microsoft.Security/assessments", "name": "b5ef903f-8655-473b-9784-4f749eeb25c6", "existenceCondition": { "field": "Microsoft.Security/assessments/status.code", "in": [ "NotApplicable", "Healthy" ] } } } } } Note: The example above is for Azure DevOps. To replicate the same policy for GitHub or GitLab: GitHub Change "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" to "microsoft.security/securityconnectors/devops/githubowners/repos" Change assessment key name "b5ef903f-8655-473b-9784-4f749eeb25c6" to "dd98425c-1407-40cc-8a2c-da5d0a2f80da" GitLab Change "microsoft.security/securityconnectors/devops/azuredevopsorgs/projects/repos" to "microsoft.security/securityconnectors/devops/gitlabgroups/projects" Change assessment key name "b5ef903f-8655-473b-9784-4f749eeb25c6" to "867001c3-2d01-4db7-b513-5cb97638f23d" For more information on Azure Policy definition structure, effects, scope, and more, review this documentation. The policy we just created uses the assessment ID for the Defender for Cloud DevOps securirty recommendation called “Code repositories should have secret scanning findings resolved” to determine whether there are any resources that are not NotApplicable or Healthy. If the policy finds an Unhealthy status code, that repository will be flagged as non-compliant because a secret was discovered. Click Save Navigate to Azure Policy Click Assignments Click Assign Policy For Scope, choose the subscription that has your connector or a top-level management group For Policy definition, choose code repositories should have secret scanning findings resolved Click Review + create Click Create Click Compliance Find the policy and click on it to view details The custom Policy gives you reporting capabilities on both compliant and non-compliant repositories. It should look like the following in the Policy Compliance details: Conclusion To review, we’ve walked through setting up a custom Azure Policy to audit repositories against a Defender for Cloud assessment that finds exposed secrets. We assigned the policy to a subscription and visualized the results in Azure Policy’s centralized Compliance view. This helps Compliance Managers, Security Operators, and Governance Teams identify non-compliant repositories across connected DevOps environments. You can then use Azure Policy reporting on these discovered secrets to implement governance for resource consistency, regulatory compliance, security, and management. Additional Resources To learn more about DevOps security, read this documentation Download (free) a special Appendix about DevOps security from the latest Microsoft Defender for Cloud book published by Microsoft Press To learn how to onboard your Source Code Management System to Defender for Cloud, read this documentation for GitHub and this documentation for Azure DevOps To learn more about the Microsoft Security DevOps (MSDO) tools, read this documentation for GitHub and this documentation for Azure DevOps
Introducing the new File Integrity Monitoring with Defender for Endpoint integration
As the final and most complex piece of this puzzle is the release of File Integrity Monitoring (FIM) powered by Defender for Endpoint, marks a significant milestone in the Defender for Servers simplification journey. The new FIM solution based on Defender for Endpoint offers real-time monitoring on critical file paths and system files, ensuring that any changes indicating a potential attack are detected immediately. In addition, FIM offers built-in support for relevant security regulatory compliance standards, such as PCI-DSS, CIS, NIST, and others, allowing you to maintain compliance.Leveraging Defender for Containers to simplify policy management in your Kubernetes Clusters
Introduction A key part of Kubernetes security includes making sure the cluster is configured to industry and company best practices. This entails controlling what users can do on the cluster and blocking actions that don’t comply with pre-defined best practices. Out of the box, Kubernetes does not provide a mechanism to write and deploy fine grained policies required per your security and compliance mandates. As a result, you will probably leverage something like Gatekeeper along with Open Policy Agent (OPA). Defender for Containers protects your Kubernetes clusters by continuously assessing them to get visibility into misconfigurations and help mitigate identified threats. To get insight into the workload configuration on the cluster, the Azure Policy for Kubernetes is deployed as part of the Defender for Containers plan. The Azure Policy for Kubernetes extends the Gatekeeper v3 admission controller webhook for OPA. Gatekeeper is needed to check if the policy is correct before enforcing it. On Azure Kubernetes Service (AKS), it is deployed as an add-on. For Arc Enabled Kubernetes, which includes on-premises clusters and clusters hosted in Google Cloud or Amazon Web Services, it is deployed as an extension. In this blog, we will go more into detail about how Azure Policy for Kubernetes, uses Gatekeeper with OPA in the Defender for Containers plan. How does the policy deployment work? The Azure Policy for Kubernetes checks with the Azure Policy service for policy assignments to the cluster, deploys policy definitions into the cluster as constraints and constraint templates and reports details back to the Azure Policy service. Figure 1 shows at a high level how the Gatekeeper works with policy and responds to admission requests. When a user makes a request to the API server, the API server will send an admission request to the Gatekeeper validating Webhook and asks if this request should be allowed to proceed. To make a decision, the Gatekeeper will consult the Policy CRs(Core Rules). The constraint shows the gatekeeper what requirement needs to be met to make the request from the API server while the template shows exactly how to make those requests. When enabling Defender for Containers on your subscriptions, it recommends deploying the Azure Policy agent on your Kubernetes clusters. Once the agent is deployed, Defender for Containers provides best practices via recommendations across all Kubernetes clusters. Some recommendations have parameters that must be configured before they can be used effectively. The only action required by the customer is to adjust policy parameters of those recommendations to the organizational policy. For example, in the recommendation "Container images should be deployed only from trusted registries", customers must define known and trusted registries. Additionally, with “Container CPU and memory limits should be enforced”, customers must define the max allowed CPU units and memory bytes in the cluster in order for Defender for Containers to report non-compliant clusters. Organizations can also leverage the “Additional Information” section of the recommendation to view parameters that need to be configured. Another parameter organizations may consider are exclusions. Organizations may have components on the cluster such as an image or container that they want to be excluded from being monitored in relevant recommendations. Where applicable, the “Additional Information” section of the recommendation would highlight the option to configure exclusions. The exclusion would apply to all relevant data plane recommendations and are not customizable per recommendation. In the recommendation “Privileged containers should be avoided”, organizations can configure exclusions based on container images. Once configured, the exclusion would apply across all data plane recommendations where an image is relevant. To be more proactive towards Kubernetes security, consider changing the recommendation from “audit” mode to “deny”. The deny effect would prevent the creation of resources that don’t satisfy the recommendation. Exporting Affected Components Once the parameters have been configured for the recommendations, you can view the affected components by navigating to the unhealthy resources tab and clicking on the unhealthy cluster. The affected components will pop up on the left blade. This information is retrieved via API calls and can be exported using a PowerShell script. Limitations Before deploying the Azure Policy Add-on please be aware of existing limitations and recommendations. Summary In this article, we demonstrated an easy way to deploy and manage the policies for your Kubernetes clusters. Through the Azure Policy for Kubernetes, which is deployed as part of the Defender for Containers plan, organizations can leverage several built-in recommendations to monitor compliance on the Kubernetes data plane. We also showed you how to view the affected components for each recommendation, export them and apply exclusions. More Information: Container security with Microsoft Defender for Cloud | Microsoft Learn Secure your Containers from Build to Runtime - YouTube Learn Azure Policy for Kubernetes - Azure Policy | Microsoft Learn Reviewers Tomer Spivak, Senior PM(Defender for Cloud) Maya Herskovic, Senior PM(Defender for Cloud Mekonnen Kassa, Principal GPM (CxE, Defender for Cloud)
