Andrew Wilson's Blog

{ ... Plan - Architect - Develop - Reflect - Improve - Repeat ... }

Azure Role Based Access Control (RBAC) | Removing Orphaned Role Assignments

Problem Space Deploying solutions into Azure that rely on Role Based Access often involve us creating IaC automation for the assignment of roles, such as: A services access to Key Vault A services access to a Key Vault specific secret A services access to a storage account A services access to a Service Bus Queue or Topic In many of these instances we may wish to leverage the source resource identity (System Assigned Managed Identity) for the assigned access.

Azure API Management | Enable Tracing for an API

Background For a while now I have made good use of the Trace functionality in the API Management (APIM) Test Client. If you haven’t, I would highly advise having a look. The Trace functionality allows us to unveil (debug) the complexity and inner workings of our reverse proxy APIs (their routing / hierarchical policies / alternate backends / caching / etc.). With the Portal this is fairly trivial to do, you simply:

Bicep | Prevent a Nasty Refactor with Function Namespaces

Problem Space There have been few times where I have landed into this particular predicament whereby either by my own doing or through the use of another’s code base, a deep nested or thoroughly utilised (parameter/variable/or other defined item) has been created with the same name as a Bicep function. As by Murphy’s law, its only once you have reached this point of no return that you realise that your items name conflicts.

Azure API Management | Unintentional Removal of Request Forwarding to Backend

Problem Space I have recently been working on an API scoped policy within API Management, the policy ideally should not be impacted by any policies defined higher up in the hierarchy. For reference, this means that any policies defined at the Product, Workspace, or Global level will not be inherited at the API scope for the given API Definition. See diagram below: Ideally this means that my API traffic will start at my non-hierarchical policy definition, conduct any policy processing prior to being sent off to the backend, and then sent back to the calling outbound system.

Azure API Management | Governing Product Visibility and Access via Groups

Overview In API Management, users and groups are a core aspect of the Developer Portal and are used to manage the visibility and access to respective products and their APIs. One of the common questions that I often get asked is, “how do I appropriately govern the groups effectively so that I can ensure that the correct groups and users have access to the appropriate resources and those who don’t… well don’t?