Who Can Access What? Designing RBAC and Identity in Azure
Who should be allowed to access an Azure resource? Azure makes it easy to create resources. The harder question comes afterwards: who should be allowed to access them? A Function App may need to read secrets from Key Vault. A Logic App may need to call APIs through API Management. A developer may need to deploy to Dev but have no access to Production. A CI/CD pipeline may need to deploy infrastructure without becoming an Owner of the entire subscription. This is where Azure Role-Based Access Control (RBAC) and Managed Identity become critical. In this article, I look at how to design access around people, applications and deployment pipelines, while keeping permissions as narrow as practical. The article covers: Azure RBAC and access scopes Least-privilege access Managed Identities Developer vs Production access boundaries Application identities CI/CD deployment permissions RBAC vs API authentication Privileged access and PIM Common RBAC design mistakes One of the key principles is simple: Give an identity only the permissions it actually needs. For example, if a Function App only needs to read secrets from Key Vault, giving it Contributor access to the entire Resource Group solves the problem with a much broader permission than necessary. Good RBAC design is not about assigning more permissions. It is about understanding: Who needs access? Why do they need it? What exactly do they need to do? At what scope should access be granted? How can that access be managed securely over time? I would be interested to hear how others approach RBAC and identity design in enterprise Azure environments. Full article: https://www.linkedin.com/pulse/who-can-access-what-designing-rbac-identity-azure-chethan-raj-ud6gc/
Update App Registration Client Secret Using Microsoft Graph REST API v1.0
Hello, I have a customer who wants to set the App registration Client Secret to 1 year. Here are the customer's requirements: For existing application registrations under ‘Certificates & Secrets’ pane, any new secrets added by owners should have the duration limited to one year. If the owner tries to set the duration greater than one year and clicks ‘Add’ button, the action should not be allowed with proper error displayed. The same behavior should also be applicable to new application registration specific secrets. It should not impact any existing secret that is present (greater or less than one year) for current application registrations. We need a way to enable and disable the global policy in case we want to disable it if something doesn’t work as expected. We don’t want to impact anything else wrt application registrations or anything in service principles. Based on the article you shared; Microsoft Entra application management policy API overview - Microsoft Graph v1.0 | Microsoft Learn Below is the script we are trying to use to add the global policy and set as default policy with isEnabled = true. As we cannot test in a different tenant, can you please confirm the snippet below will work for the above requirements? MgPolicyAppManagementPolicy | select * $policy = @{ "displayName" = "Enforce Max Lifetime for Secrets" "description" = "Policy to enforce a maximum lifetime of 1 year for any new secrets." "applicationRestrictions" = @{ "passwordCredentials" = @{ "maxLifetime" = "P365D" # ISO 8601 duration format for 1 year } } } New-MgPolicyAppManagementPolicy -BodyParameter $policy Update-MgPolicyDefaultAppManagementPolicy -id <ABOVE_POLICY_ID -IsEnabled $true I tried to test it in my own tenant, but I ran to a permission issue. Can someone please confirm if this snippet works against the customer's requirements? Thanks.
