Replies: 0 comments 2 replies
-
Azure Active Directory is always "fun" to throw into the mix. The support for it in Bicep (and ARM for that matter) is close to none, and for handling such things as client secrets, reply urls, and more I usually have to break into cli scripting or PowerShell. What you generally want is to avoid having to use things like secrets in code, and not just avoiding hardcoding it, but also avoiding it entirely by using EasyAuth/managed identity/workload identities/take your pick. The root problem is that there isn't a developer story at the tenant level. For Azure resources in general you can fence off things and say "this subscription is for dev purposes only and cannot access production level data". If you have just one AAD tenant you can't really do the same thing, and you can't give devs full access to do admin consent and the like. I often find myself using a test tenant when doing identity-related development, but that's not a perfect solution either (especially if it's not a solo project). I agree that this is something that should be considered in the "dev ify" journey though. |
Beta Was this translation helpful? Give feedback.
-
Oftentimes to kick off development some Azure Active Directory is required. From the perspective that a repo should be easy to build and run (ideally codespaces compatible) I am looking for solutions.
Considerations:
Beta Was this translation helpful? Give feedback.
All reactions