Bug: Issue with Azure DevOps Approval Configuration

[oZakari]

Is there an existing issue for this?

• I have searched the existing issues

Infrastructure as Code Type? (Required)

bicep

PowerShell Module Version (Optional)

4.2.3

Bootstrap Module Version (Optional)

4.2.0

Starter Module? (Required)

bicep - complete

Starter Module Version (Optional)

0.21.0

Input arguments of the ALZ-PowerShell-Module (Optional)

Feedback from field CSA "Used the Accelerator with Bicep and DevOps. We had four users added to the apply_approvers array. These users seem to have been added to a group alz-mgmt-approvers. However, that group has custom permissions, which do not include permissions to the apply Service Connection, which is where the approval is created.

So the users in that group can't perform the approval, they just don't see the Approve button for the service connection.

I am just typing this while working with a customer so I may be missing something obvious instead."

Debug Output/Panic Output (Optional)

Expected Behaviour (Required)

Approvals required to the "apply/deploy" environment

Actual Behaviour (Required)

Approvers required at the service connection level.

Steps to Reproduce (Optional)

No response

Important Factoids (Optional)

No response

References (Optional)

No response

[jaredfholgate]

I disagree strongly with the reasoning behind using approvals associated to the environments.

Happy to explain the reasoning, but it essentially comes down to the environment not being a robust mapping to the identity. The service connection is a wrapper for the identity and therefore you are approving the use of that identity. The environment is defined in YAML and someone malicious could potentially just remove it or replace it, thereby bypassing approval. With GitHub it is part of the OIDC subject, so more robust there, but not for Azure DevOps.

I haven't come across a perms issue for this yet, so keen to understand the exact issue. I think we can add the necessary permission easily enough.

We can also update to add pre-existing group(s) as an alternative solution.

[oZakari]

I disagree strongly with the reasoning behind using approvals associated to the environments.

Happy to explain the reasoning, but it essentially comes down to the environment not being a robust mapping to the identity. The service connection is a wrapper for the identity and therefore you are approving the use of that identity. The environment is defined in YAML and someone malicious could potentially just remove it or replace it, thereby bypassing approval. With GitHub it is part of the OIDC subject, so more robust there, but not for Azure DevOps.

I haven't come across a perms issue for this yet, so keen to understand the exact issue. I think we can add the necessary permission easily enough.

We can also update to add pre-existing group(s) as an alternative solution.

Thanks for the additional insight on that! That makes sense to me in terms of being able to potentially remove the environment although probably not as concerning in an internal repository but still valid. I'll take a look at the permissions aspect and see if I can replicate.