Skip to content

Conversation

@JamesDawson
Copy link
Contributor

No description provided.

### Service Account
Whilst it would be trivial to setup a dedicated AAD user account with the required permissions to run the process, such an identity cannot always be used to natively execute a pipeline within CI/CD tools (e.g. Azure DevOps, GitHub Actions).

Therefore it would be necessary for the pipeline to perform a 'runas' operation when communicating with the Azure DevOps REST API. This in turn means that the credential for this user needs to be retrievable (e.g. from key vault), but this clashes with the goal to minimise the surface area for attacking the trusted identity's credential.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this differ from the the need to retrieve the credentials for the service principal that the pipeline operates as?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The credentials for the service principal only need to be known at the point that the service connection is registered, after that, ADO handles storing the credentials and making them available to pipeline.

Those concerns, as they relate to this additional identity, would get pushed down into the pipeline process itself (e.g. the codeops script).

Copy link
Contributor

@MikeEvansLarah MikeEvansLarah Mar 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you create a generic service connection for the service account and handle it in a similar way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants