Building Secure Microservices in Azure - Jimmy Bogard - NDC London 2023

Building microservices can be easy, but securing them is hard. We have external and internal applications, APIs, queues, users, and more. Each might use a different authentication and authorization strategy, depending on customer and system needs. The stakes are high and there is no margin for error!
In this talk, we’ll look at the different categories of applications and users, and what possibilities we have for securing them. We’ll also look at what Azure provides for securing internal users and applications, and an external provider for external users and applications. We’ll also cover different authentication and authorization strategies, and how we can map these to our various communication scenarios.
Finally, we’ll look at a full end-to-end example using .NET 6 and Azure, building out a playbook for the common and not-so-common scenarios we encounter.
Check out our new channel:
NDC Clips:
‪@ndcclips‬
Check out more of our featured speakers and talks at
ndcconferences...
ndclondon.com/

[@mouradaissani8957]

thnx Jimmy, u well deserved my star on ur github ;)

[@allmhuran]

Good talk that finally went into the *actual implementation* that a developer would have to physically create instead of just a talk that says "use OAuth 2 with AAD!".
What wasn't clear to me was why I didn't hear the phrase "managed identity" until the very end. Overall, this is trying to work using the same philosophy as windows auth for on prem domains using specific domain accounts to run things like IIS apps and windows services, and security groups to grant permissions to users, but for some reason it's all far more obscure in azure.
It's also rather amusing that the claim of the technology is "you just define roles and then set everything up via config", and then we go and paste 200 lines of C#, lol.

[@coderider3022]

He should have mentioned easy auth feature for the app service and what the APIM can do. If your closed to internal clients only and have azure ad, I’d recommend this route to start with and keep you app simple with no auth code. Passing jwt claims to the app via headers is much simpler and makes local dev simpler.

[@MrNorthCat]

The main question- to protect against what threats? How to assess reliability of particular method?
And only then - how to do it?

[@osman3404]

I SWEAR I went similar headache not too long with Microsoft AD

[@coderider3022]

41:15 really wish i could use scope for the app / client credentials. Azure wants them uniquely named. Graph api does it right.

[@MarusykRoman]

good talk but a lot of pulumi. most projects don't use pulumi so if the talk was about "click click on AZ portal" it wold be more generic and useful to all who get stuck with that Azure AD

[@weifengmao]

I don't think currently app roles assigned to service principals through an aad group propagates correctly. And the UI doesnt exist in portal to manage the assignment. Its a bit clunky. Also for local development you can use azure default credentials to retrieve logged in user token through az cli or vs or vscode