Open elbardel opened 1 year ago
This issue has had no activity in 90 days. Please comment if it is not actually stale.
This is still relevant.
Until this is wired up, it is possible to use the Azure CLI task to extract the AAD token and use it for Artifacts. I only have a sample for Actions: https://github.com/johnterickson/actions-oidc-demo
This issue has had no activity in 90 days. Please comment if it is not actually stale.
not stale
With current push to use managed identity this is still relevant and valid. https://github.com/microsoft/artifacts-keyring/issues/60 issue is somewhat related to this. Looks like artifacts-keyring uses artifacts-credprovider and PAT instructions are removed from the artifact feed pages. They are suggesting using artifact-keyring but unable to use managed identity seems to be the blocker.
Written an ado extension that can be used to pull auth tokens from federated credentials. The only sticking problem is that this does not support passing a bearer auth token and soft-requires a plain PAT token (which is now being hard phased out)
release 1.2.0-alpha now natively supports MI / SP set up instructions can be found on the PR description. Please let me know if you have and feedback or find any issues!
I had a look at using this with our Team City hosted builds, but being locked to only using a certificate is a bit of a pain point. Team City can handle distributing the Service Principal secret securely (and this is the approach we take with other jobs that need to auth), but not distributing a certificate onto those build agents. Our preference would be for the plugin to support secret based authentication - then it's our choice as to how we want to authenticate
I know that secrets is explicitly (and intentionally) disallowed because of bad security practices, but it might be good to support WIF (which it currently also does not do so either)
I had a look at using this with our Team City hosted builds, but being locked to only using a certificate is a bit of a pain point. Team City can handle distributing the Service Principal secret securely (and this is the approach we take with other jobs that need to auth), but not distributing a certificate onto those build agents. Our preference would be for the plugin to support secret based authentication - then it's our choice as to how we want to authenticate
Thank you for your feedback. While we understand this is additional configuration and set up, at this time, we are not considering adding secrets. However, if anyone is interested in secrets, please upvote the above comment. Depending on the demand, we can reconsider incorporating this work in the future.
I know that secrets is explicitly (and intentionally) disallowed because of bad security practices, but it might be good to support WIF (which it currently also does not do so either)
Please let us know what ADO Feed WIF scenarios you are interested in being supported.
AzureDevOps released in public preview a feature to enable authentication with Azure Active Directory service principals & managed identities and they are encouraging people to use it for automation instead of PATs.
It would be useful to have support for managed identities authentication in artifacts-credeprovider, in the same way it already supports AAD authentication with users. The managed identity client id could be provided in an environment variable.
This would greatly simplify the set up for automation.