[analysis] GH action to test azd deployment principal mismatch

[anfibiacreativa]

because the UAMI assigned principal and some templates have a different principal assignment, we're running into a mismatch.

ERROR: error executing step command 'provision': deployment failed: error deploying infrastructure: deploying to subscription:

Deployment Error Details:
UnmatchedPrincipalType: The PrincipalId 'a61472c60dc14425ac1a8ede3955e55f' has type 'ServicePrincipal' , which is different from specified PrinciaplType 'User'.
UnmatchedPrincipalType: The PrincipalId 'a61472c60dc14425ac1a8ede3955e55f' has type 'ServicePrincipal' , which is different from specified PrinciaplType 'User'.
UnmatchedPrincipalType: The PrincipalId 'a61472c60dc14425ac1a8ede3955e55f' has type 'ServicePrincipal' , which is different from specified PrinciaplType 'User'.

TraceID: 7dc0c1710a91ebcbef32dff73560b11d

Failed to list resources: No value for given attribute

We need to solve this.

[anfibiacreativa]

@vhvb1989
Repro steps:

1. Go to https://icy-moss-0a539981e.2.azurestaticapps.net/ and run the validation for any of the templates in the tiles.
2. Come back to this repo and go to Actions.
3. Find the running job for https://github.com/Template-Doctor/template-doctor/actions/workflows/validation-template.yml
4. Find the mismatch error in the logs

Related files:
https://github.com/Template-Doctor/template-doctor/blob/a08eaa4d2b69092be6291ff8302ecd89acd299dd/.github/workflows/validation-template.yml#L45

CC: @kristenwomack @spboyer

[vhvb1989]

@anfibiacreativa , this is somehow expected. Let me explain.

A template owner is responsible from defining the bicep-template for their project. When you are defining some resources in bicep, you can be explicit about the use-case for the resource. For example, when a role-assignment is defined, folks can explicitly describe that the role is expected to be granted to a user or a service principal. People can omit this field as a way to say something like "I don't care if the role is given to a user or service-principal". But when this is defined, the template is creating an explicit expectation for deploying the template for either a user or a service principal.

Then, when it comes to a tool like the template-doctor, it always operates under a service-principal (the UMI). This means it is limited to deploy only those templates which either:

• Do not define an explicit user-type for resources and works for all (users, groups, service principal)
• Explicitly define the deploy mode for a service-principal
• Supports a way to define the user-type by using input bicep parameters.

So these are the options I see for the template-doctor:

• A) Mandate templates to omit being explicit for user-type. Make template-doctor to check there are no resource definitions specific for user-type = user. Fail fast if there is one found and consider the template not compliance with template-doctor validations. Then tell folks how their template must support both user types.
• B) Set and validate an expected guideline. Create a convention like "If you use resource definitions with user-type, your template MUST define an input variable to set it AND the input parameter must be mapped to an ENV VAR called TEMPLATE_USER_TYPE using the main.parameter.json". This way, when template-doctor runs, it will set the user-type to service principal and work just fine. The guideline can let the input to be default to user.
• C) Manually override. When it runs, make template-doctor to start by creating a copy from the infra files, then find any user-type=user from the resource definitions (bicep) and change the value to service principal. Then continue with deployment.

My personal preference would be option B). It's not as intrusive as C) and neither as relaxed as A).
It also helps a template-author to think about running in CI mode as part of the infrastructure-design (assuming there won't be always a user deploying the template).
Option A) is so relaxed that it could lead to unexpected scenarios.

[anfibiacreativa]

So this we had already documented in troubleshooting. I will create additional logic for Copilot to open a PR when we come across this issue in validation phase.
https://github.com/Azure-Samples/azd-template-artifacts/blob/main/docs/development-guidelines/trouble-shooting.md#error-unmatchedprincipaltype-the-principalid-id-has-type-serviceprincipal--which-is-different-from-specified-princiapltype-user
CC: @kristenwomack