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.AKS Security Dashboard
In today’s digital landscape, the speed of development and security must go hand in hand. Applications are being developed and deployed faster than ever before. Containerized application developers and platform teams enjoy the flexibility and scale that Kubernetes has brought to the software development world. Open-source code and tools have transformed the industry - but with speed comes increased risk and a growing attack surface. However, in vast parts of the software industry, developers and platform engineering teams find it challenging to prioritize security. They are required to deliver features quickly and security practices can sometimes be seen as obstacles that slow down the development process. Lack of knowledge or awareness of the latest security threats and best practices make it challenging to build secure applications. The new Azure Kubernetes Service (AKS) security dashboard aims to alleviate these pains by providing comprehensive visibility and automated remediation capabilities for security issues, empowering platform engineering teams to secure their Kubernetes environment more effectively and easily. Consolidating security and operational data in one place directly within the AKS portal allows engineers to benefit from a unified view of their Kubernetes environment. Enabling more efficient detection, and remediation of security issues, with minimal disruption to their workflows. Eventually reducing the risk of oversight security issues and improving remediation cycles. To leverage the AKS security dashboard, navigate to the Microsoft Defender for Cloud section in the AKS Azure portal. If your cluster is already onboarded to Defender for Containers or Defender CSPM, security recommendations will appear on the dashboard. If not, it may take up to 24 hours after onboarding before Defender for Cloud scans your cluster and delivers insights. Security issues identified in the cluster, surfaced in the dashboard are prioritized to risk. Risk level is dynamically calculated by an automatic attack path engine operating behind the scenes. This engine assesses the exploitability of security issues by considering multiple factors, such as cluster RBAC (Role Based Access Control), known exploitability in the wild, internet exposure, and more. Learn more about how Defender for Cloud calculates risk. Security issues surfaced in the dashboard are divided into different tabs: Runtime environment vulnerability assessment: The dynamic and complex nature of Kubernetes environments means that vulnerabilities can arise from multiple sources, with different ownership for the fix. For vulnerabilities originating from the containerized application code, Defender for Cloud will point out every vulnerable container running in the cluster. For each vulnerable container Defender for cloud will surface remediation guidelines that include the list of vulnerable software packages and specify the version that contains the fix. The scanning of container images powered by Microsoft Defender Vulnerability Management (MDVM) includes scanning of both OS packages and language specific packages see the full list of the supported OS and their versions. For vulnerabilities originating from the AKS infrastructure, Defender for cloud will include a list of all identified CVEs (common vulnerabilities and exposures) and recommend next steps for remediation. Remediation may include upgrading the Node pool image version or the AKS version itself. Since new vulnerabilities are discovered daily, even if a scanning tool is deployed as part of the CI/CD process, runtime scan can’t be overlooked. Defender for cloud makes sure Kubernetes workloads are scanned daily compared to an up-to-date vulnerability list. Security misconfigurations: Security misconfigurations are also highlighted in the AKS security dashboard, empowering developers and platform teams to execute fixes that can significantly minimize the attack surface. In some cases, changing a single line of code in a container's YAML file, without affecting application functionality, can eliminate a significant attack vector. Each security misconfiguration highlighted in the AKS security dashboard includes manual remediation steps, and where applicable, an automated fix button is also available. For containers misconfigurations, a quick link to a built-in Azure policy is included for easily preventing future faulty deployments of that kind. This approach empowers DevOps & platform engineering teams to use the “Secure by Default” method for application development. To conclude - automated remediation and prevention can be a game changer in keeping the cluster secure- a proactive approach that can help prevent security breaches before they can cause damage, ensuring that the cluster remains secure and compliant with industry standards. Ultimately, automated remediation empowers security teams to focus on more strategic tasks, knowing that their Kubernetes environment is continuously monitored and protected. Assigning owners to security issues Since cluster administration and containers security issues remediation is not always the responsibility of a single team or person, it is recommended to use the “assign owner” button in the security dashboard to notify the correct owner about the issue need to be handled. It is also possible to filter the view using the built-in filters and assign multiple issues to the same person quickly. Get Started Today To start leveraging these new features in Microsoft Defender for Cloud, ensure either Defender for Container or Defender CSPM is enabled in your cloud environments. For additional guidance or support, visit our deployment guide for a full subscription coverage, or enable on a single cluster using the dashboard settings section. Learn More If you haven’t already, check out our previous blog post that introduced this journey: New Innovations in Container Security with Unified Visibility and Investigations. This new release continues to build on the foundation outlined in that post. With “Elevate your container posture: from agentless discovery to risk prioritization”, we’ve delivered capabilities that allow you to further strengthen your container security practices, while reducing operational complexities.
Unleashing the Power of Microsoft Defender for Cloud – Unique Capabilities for Robust Protection
So you have implemented a non-native Cloud Security Posture Management solution but there are security gaps that you might not have considered. How Defender for Cloud is uniquely positioned to secure your cloud attack surface.
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 DevOpsLeveraging 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)Policy Distribution Dashboard for Microsoft Defender for Cloud
Understanding the current state of your environment is the first step towards improving its security posture. Microsoft Defender for Cloud is designed to strengthen the three pillars every enterprise relies on which is Protection, Detection & Response providing you CSPM & CWPP functionalities. In Defender for Cloud, the posture management features provide Visibility and hardening guidance and the central feature that enables you to achieve these goals is Secure Score. Defender for Cloud continually assesses your resources, subscriptions and organization for security issues, and it aggregates all the findings into a single score by providing you list of recommendations. Typically, these are gaping holes that need to be fixed ASAP, while some recommendations are more long-term or just less critical and some more critical. Current Challenge One of the questions we constantly get asked is, How do I ensure that the Security posture will not start deteriorating again after the fixes have been made (or) how do I ensure I apply guardrails at the beginning of deployment phase for every service in Azure. It is often the case that development teams have full control of their subscriptions/resources. As a result, the configurations start to drift. The cure is simple, we need to have a security baseline defined. Before you start reading about the proposed solution, it is important to understand, Defender for Cloud and Azure policies work together to help monitor and report on compliance in your environment. Like security policies, Defender for Cloud initiatives are also created in Azure Policy. You can use Azure policy to manage your policies, build initiatives, and assign initiatives to multiple subscriptions or for entire management groups. The default initiative automatically gets assigned to every subscription in Defender for Cloud and that is Azure Security Benchmark. Azure Security Benchmark (ASB) consolidates Microsoft security best practices in Azure. It’s a great resource for design decisions, and the controls are mapped to industry standards. We have also created a policy set in Azure which can be used for monitoring resource compliance against the baseline. This widely respected benchmark builds on the controls from the Center for Internet Security (CIS) and National Institute of Standards and Technology (NIST) with a focus on cloud-centric security. Almost every recommendation from Defender for Cloud has an underlying policy that is derived from a requirement in the benchmark. To learn about the built-in policies that are monitored by Defender for Cloud, check this out. Here you can find all the Azure Policy definitions in the Defender for Cloud category. Proposed Solution Up until now, there was no single view with which you could visualize all the policies you have assigned to monitor compliance of your environment. You had to browse through many different blades in Azure to assess and obtain this information. With this blog, I’m introducing you to a workbook that acts as a single pane of glass representing the policies and baselines across multiple subscriptions in Azure, in your environment as the first crucial step is to inventory and gain visibility. What’s in the Dashboard The new Policy Distribution Dashboard for Microsoft Defender for Cloud provides a unified view and deep visibility into the configuration of your overall policy structure in Azure. The dashboard is powered by Azure Resource Graph (ARG) queries and divided into different sections. The workbook can be edited, and all queries can be modified to meet your needs. The workbook provides different sections like: Initiatives that’s assigned to the subscriptions The recommendations that are exempted and that are policy disabled List of Custom policies Regulatory Compliance Assessment State Policies by effect Compliance by policy assignment How to Deploy The Policy Distribution Dashboard is available in the Microsoft Defender for Cloud GitHub Repo page, under Workbooks and can be accessed directly with its direct URL The workbook can be deployed quickly in the Azure Commercial and Gov cloud environments by clicking the respective “Deploy to Azure” buttons on the workbook page. How to Use To use this dashboard, you need at least Reader permission at the subscription level. Assuming you have the required permissions, watch the screen capture below to learn about how to navigate through and use the dashboard. Conclusion The Policy Distribution dashboard provides valuable information about your policy assignments and it’s status. The workbook is available to all customers free of charge and does not require you to be a paid customer of Microsoft Defender for Cloud. Additional Resources To learn more about Microsoft Defender for Cloud, visit: https://aka.ms/ascninja To learn about Microsoft Defender for Cloud workbooks, visit: https://docs.microsoft.com/en-us/azure/security-center/custom-dashboards-azure-workbooks Acknowledgements Special thanks to Lior Arviv for the partnership in reviewing and providing feedbacks on the artifact and reviewing article. Many thanks to @Rebecca Halla & YuriDiogenes in supporting this initiative and suggesting feedbacks.7 steps to author, develop, and deploy custom recommendations for Windows using Guest Configuration
Overall, there is 7 steps documented process to author, develop, and deploy; this blog will summarize each step however will link to each Azure Doc along that step so you can get full details if desired.Configure Security Center bundle pricing with Azure Policy
With the new Security Center pricing tier options per resource type, customers have asked us how to configure these at the (Root) Management Group scope so that any new (or existing) subscription will be automatically configured for the Standard pricing tier, allowing Security Center to automatically protect your resources. As you may know, we have recently added Storage accounts protection in Security Center: The most efficient way to achieve that objective is to leverage Azure Policy. With the new Azure Policy aliases for Security Center you can author Azure Policy definitions for each of the 4 resource types. To get you going, I've written 4 Azure Policy definitions which you can add to 1 single initiative to either enforce it on new subscriptions, or to set it on existing subscriptions. The Azure Policy definition (deployIfNotExists) for setting the Standard pricing tier for Storage Accounts looks like this: Add the 4 policy definitions for each bundle pricing tier: Once you have added the 4 Policy definitions, you can add them to 1 single initiative: Finally we assign the Initiative: It will take around 30 minutes for a new assignment to become active: After a while we can see the compliance state for the Initiative: Clicking on one of the definitions shows us why it is not compliant. From here we can "remediate": Remediation is in progress and then done: The 4 Policy definitions (deployIfNotExists) for the bundle resources can be found here.
