compose: separate out local permissioning

[weikanglim]

Context

With composability in alpha stage today, we create and assign user permissions to the deployer principal ID (typically the user) within the Bicep deployment. This enables the local user to connect to all Azure resources for a more frictionless local-Azure dev experience.

However, this creates a challenge when promoting the environment into CI/CD, which typically involves running azd infra synth followed by azd pipeline config. The current behavior is that provisioning fails in CI/CD -- and the user is responsible to remove the local user permissions from the CI/CD pipeline.

Proposal

A better story to tell here is some sort of ACL permissions list that is separated out from the main deployment pipeline, whether via a separate directory or via a Bicep boolean parameter. Some brief descriptions below:

1. Separate directory: I could imagine, for example, a ./infra/local-perm directory that has Bicep or YAML configuration files that capture the set of resources and associated roles to assign the current running user.
2. Bicep boolean variable: A common one seen today in templates is isRunningOnGh to control the behavior within Bicep. This is much more straightforward, but I have a general question if this is really best practice -- whereas a more isolated approach seems to look cleaner.

Regardless of approach, this should allow any user in a shared repository to assign themselves permissions, if they should choose to do so.

Questions

Supposedly if we went down this path, some questions remain:

1. Do we expect that in the azd add + azd provision flow, azd to automatically apply local permissions?
2. Do we feel comfortable taking a dependency on some CI detection logic? azd does currently does implement CI detection internally in ci.go to some level of robustness. There isn't a standard for CI detection (although CI is a common env variable) that I'm aware of, but it does support a comprehensive list of different providers.

[weikanglim]

A tricky part of the implementation if we're going with Bicep is to be able to figure out resource types and role assignments in a different module.

In a naive implementation, azd could iterate AZURE_RESOURCE_** variables right now and dynamically figure out the resource type through a series of ARM calls, and have a mapping table between resource type and role assignment name/IDs.