Andrew Wilson's Blog

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

Speaking | Azure Security Do's and Don'ts: A Developer's Checklist for Secure Azure Applications

I recently had the privilege to be hosted on the Azure on Air podcast by the Turbo360 team. I had a great conversation with Lex discussing the importance of a “security first” mindset in the world of Azure solutions, and how this mindset should be carried out as a priority in every stage from Requirements Gathering, Design, Development, and Release. During our time together we discussed topics such as:

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.