Cloud-custodian: azure - support for multi-subscription azure policies

[justinhauer]

From speaking to @kapilt, and some of you on the Azure side of the project, c7n_org is not currently supported in Azure functions - although he didn't explicitly spell out the reasons why it wouldn't work. Is there any discussion on supporting this in functions?

My use case is a fairly lengthy set of tagging policies that would be ubiquitous across subscriptions (with logic to add tags or send emails if specific tags are not set), and it seems like the current two options are to have a lot of duplicate functions sitting in one Resource Group that would act on multiple subscriptions, or to set up a different APP service plan and functions in each subscription you want to run in. In stead of these two options it would be great to have some azure functions with c7n support that could target multiple subscriptions, and cut down on deployment of duplicate functions

[kapilt]

this really isn't about c7n-org, its about azure functions that support multiple subscriptions. c7n-org is a cli that executes policies across subscriptions/accounts/projects in parallel.

[kapilt]

I'm a little unclear on the two options, why would option 1 have duplicate functions?. in aws multi-account, we effectively just setup a single policy function, and feed it events from multiple accounts.

as long as there is underlying platform support for event streams across accounts and subscribing to them, I'm a little unclear what the issue is, ie. why this doesn't work today. afaics it should easier in azure since there isn't a need to change auth info when working across subscriptions. I also don't see anything specific to the subscription in the event grid subscription filter.

@aluong @erwelch @logachev @stefangordon could any of you shed any light on this?

[justinhauer]

If this is a misunderstanding of mine, please point out. From the documentation and when deploying them, when deploying an azure function it either targets the environment variables you've set with your azure credentials for that subscription, or targets a different subscription based on the additional environment var set at the time - but not being able to feed the function events from multiple subscription like @kapilt has said they do in AWS above ^:

By default the function is both deployed and executed with the credentials and subscription ID you have configured for the custodian CLI. You may optionally provide environment variables to use exclusively at function execution time which also allow you to target your policy towards a subscription ID different than the one to which you are deploying.

The following variables will be obeyed if set:

AZURE_FUNCTION_TENANT_ID
AZURE_FUNCTION_CLIENT_ID
AZURE_FUNCTION_CLIENT_SECRET
AZURE_FUNCTION_SUBSCRIPTION_ID

These will be used for function execution, but the normal service principal credentials will still be used for deployment.

[kapilt]

the function and the event grid subscription need to live in an azure account subscription and have a credentials which those env vars refer to. If the credentials have access across subscriptions and the event delivery is setup for cross subscription events, then afaict that would work but its also an if

[update] talked to @aluong there's a couple of different things in play.

What needs doing

1. event grid events for resource manager are single subscription, ie. if I talk to event grid in subscription a, and ask for arm events it will only show the events in subscription a. That means we would need to setup something with a foot print in each account to get arm event hub delivery to a centralized policy function.

2. The subscription id the function operates against is currently static per provisioning, we would need to have it find and set the subscription id per the event source.

Thoughts on implementation

1. is a little more problematic, in aws and gcp for centralized policies, we typically have the user do a one time out of band setup (cwe bus, gcp org audit log), and then we'll use that transparently. But thats because we can filter our policy's subscription to the centralized event stream. in azure we have to create a subscription filter per policy in the target accounts, as well as reference a pre-existing storage queue.

2. seems relatively straightforward from a dev perspective.

so there's definitely work here to be done, and needs more thought. one idea would be to see if event grids can be a downstream target of each other, so we can do our filtering in the centralized subscription per extant usage.

[aluong]

I will point out that although we can add this support for a single function to hit multiple subscriptions, you should also consider the "blast radius" of your Function. If each Function can hit only 1 subscription at a time, the impact is obviously smaller and you can do more granular deployments. However, it does mean more maintenance because you have more Functions.

I'll add some additional details that will be required for this to work:

• Initialization of the Custodian session must be done after the event is parsed, because it is subscription dependent
• We will need to document that every subscription will need to grant access to a "master" service principal that can operate on all of them.
• If we want custodian to handle the creation of the creation of the EventGrid subscriptions in each sub, we will need to update the provisioning properties. I am not clear if it would be better to have... Option 1: one policy where the Function is deployed and a different policy/tool where we purely subscribe other subscriptions. Option 2: one single policy that deploys 1 Function and subscribes all of the other subs at the same time.

[logachev]

Hey @justinhauer I added support for Azure Functions & Management Groups.
Please see the updated docs: https://cloudcustodian.io/docs/azure/advanced/azurefunctions.html