Видео

Hi Simone. For clarity our move to OIDC improved our security posture. Previously we were using a compute instance managed identity which is only possible with a self-hosted runner. Any workflow running on that runner can leverage the managed identity. With OIDC the auth is decoupled from the runner and scoped to the repository, etc. In our scenario it makes no difference whether we use Microsoft-hosted (GitHub-hosted) runners or self-hosted since we are only hitting public Azure end points. Could a self-hosted runner potentially improve our security posture further? Potentially as we could use private networking to connect to our state storage account. However this also limits our scalability and parallel run limits, so for us it was a bonus to be able to move to Microsoft-hosted agents since it didn’t impact our security posture for testing these open source modules. We are not handling sensitive data, etc. OIDC allows us to use granular permissions, scope to a specific workflow template and stop forked PRs from possibly triggering our end to end tests without our oversight, which was a risk before. Hope that helps.

I recommend looking at Managed DevOps Pools as a hybrid solution.

Yes that is correct, subscriptions are meant to be created first before deploying ALZ. You can see a nice diagram here learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/#landing-zone-journey

Yeah, like it was with PSarm...

These are very much on our list to do, but we have just released some self-service labs for both Bicep & Terraform so check these out in the meantime azure.github.io/Azure-Verified-Modules/resources/#-labs

We have a video for this planned. Stay tuned!

I believe the difference is the additional management group level that is crossed out in section discussed by Matt. The dev, test, and prod subscriptions can be under Corp but they can't be under dev, test, and prod management groups under the Corp management group. This discussion is about management groups, not subscriptions. Kevin's did not have the dev, test, and prod management groups.

Thanks @bangash830. If it requires private corp connectivity it would be corp. We recently documented this a bit more here: learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity#design-area-overview Corp only applies policies to prevent public IPs from being attached to NICs, which means app GWs etc all can still exist in corp, if requried

@@MicrosoftCAE Thank you for your reply, and yes the recent document regarding network topology and connectivity is much clear.

Hey Mike, please raise an issue over on our terraform repo and we can take the conversation further there: github.com/Azure/terraform-azurerm-caf-enterprise-scale

Same here. We would be using the whole thing if not for the lack of MG flexibility. Without that, we're stuck borrowing and modifying what code we can and writing the rest from scratch.

Hey Duraid, thanks for the feedback. I think the point of ALZ is to set you up for long-term success and growth. We know that migrating resources out of single subscription environments can be painful, depending on the services you have within it. Also having a single subscription approach can cause: - Running into Resources/Quota limits faster and when you do, you dont have a scalable way to handle this. - Apps can be impacted by noisy neighbours, using quota they may need etc. - Complex RBAC assignments - hard to give higher level of control to app/workload teams in shared single subscription model - Larger blast radius should a single subscription become compromised Management groups help you enable, operate and govern and multi-subscription environment at scale. Hope that helps

@@MicrosoftCAE Thanks for the response. The advantages were mentioned in the video. Thanks for re-iterating them. Non of the trade-offs were mentioned however which an unbalanced design decision. So now we build skyscrapers for everybody even if they need a couple of rooms just in case you need them in the future?

@@duraidh7299 I think CAE's response was valid, and I'll ask. How does having multiple subscriptions increase complexity? If anything, it allows you to reduce complexity as your company's cloud adoption goes. As architects, we should design environments that scale well. As outlined in the video, a single subscription can run into very painful scalability issues. A multi-subscription environment on the other hand might avoid those. If the complexity is not large (and there is no additional cost involved), why not create the more scalable solution? One final question that I'll ask that probably could have summarized my entire response. What about multiple subscriptions do you find more complex than a single subscription? The requirement for additional VNet Peering perhaps?

@@tharagz08Complexity

Hey, thanks! The TLDR on Corp & Online are as follows: Corp == Corporate connected applications, that require hybrid connectivity back to on-premises or other VNet spokes via traditional Layer 3 Routing (think VNet Peering to a Hub etc.) Online == Workloads that don't need traditional Layer 3 routing to on-premise or other VNet spokes. And if they do require connectivity to them they would either interact via each applications API exposure "publicly" (over the MSFT backbone if all in Azure) or use service like Private Link to connect between each other without the need for VNet Peering. We are actually creating a document in CAF for just this topic in terms of how Corp & Online Networking should be done in more detail and some common scenarios. Stay tuned.

Hey, yes this is indeed best practice. We only advise creating additional Management Groups if they have different governance requirements. Checkout the guidance we have on Tailoring ALZ (aka.ms/alz/tailoring)

Azure Policy can be applied at the Management Group, Subscription, Resource Group or individual resource level. If you apply a policy at a higher level, it gets inherited down. If there is a more restrictive policy it will always win, regardless of the level it has been applied. Meaning, it does not matter if the policy is applied on management group or individual resource level, the deny will win for the resources the policy is assigned to. If policies are not conflicting, they will be complementary. In your example if I felt I was going to apply a more restrictive policy, I would consider applying it at a lower level for testing. Also, we should strive to have production and non-production versions of our applications, so ideally, we would be able to apply the more restrictive policy to the non-production side first, test and validate, then roll into production once we felt comfortable. As mentioned in the video you can deploy Policy in Audit mode, so following the above feedback with this, you should be able to accomplish what you are asking: learn.microsoft.com/en-us/azure/governance/policy/concepts/effects

@@tharagz08 audit mode with some validation process makes most sense. Your example works but I was specific about testing policy applied at the root, or more specifically corporation subroot which are intended to be inherited by all, like a change nist or something.

@@evolagenda I think audit mode would make the most sense in that scenario then.

Hey Jin, I think there are a couple pointers in the Video's Metadata above :)

Thanks Matt. Stay tuned we have another video planned for just this.

@@MicrosoftCAE awesome, that would be amazing, looking forward to it 😎

Would be really great with some practical examples of the scaling issues. Are about to decide on MG structure and tend to go for MGs on prod and dev.

Funny you should ask, as we're currrently working on recording some epsiodes for the Azure Enablement Show which will include demos using our Bicep and Terraform implementations. I'll try to remember to post links here once they go live!