search

Azure / azure-cli

Azure Command-Line Interface
MIT License
3.99k stars 2.96k forks source link

Document --sdk-auth as deprecated #20743

Open devlead opened 2 years ago

devlead commented 2 years ago

In #19949 we can read

--sdk-auth was there since Nov 14, 2017 (https://github.com/Azure/azure-cli/commit/8346147d0da04063bd9000d1b370b2d65204cda8 from https://github.com/Azure/azure-cli/pull/5217). Azure SDK is not consuming it anymore, so we marked it as deprecated in https://github.com/Azure/azure-cli/pull/19414.

Please simply forget about it and do not use it in any way.

Originally posted by @jiasli in https://github.com/Azure/azure-cli/issues/19949#issuecomment-948194997

This has been/is used by many build systems, and it's still documented without any hint of being deprecated on https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az_ad_sp_create_for_rbac

So think this needs to be clearly documented there, and what should be used instead with i.e. GitHub Action for Azure CLI which has this documented as their preferred way https://github.com/Azure/cli#configure-azure-credentials-as-github-secret

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

jiasli commented 2 years ago

This has been/is used by many build systems, and it's still documented without any hint of being deprecated on https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az_ad_sp_create_for_rbac

This is actually a problem of the document: https://github.com/MicrosoftDocs/azure-docs-cli/issues/2720.

So think this needs to be clearly documented there, and what should be used instead with i.e. GitHub Action for Azure CLI which has this documented as their preferred way https://github.com/Azure/cli#configure-azure-credentials-as-github-secret

@N-Usha, @kaverma, perhaps you can help with the removal of --sdk-auth (Azure/github#152)?

andersson09 commented 2 years ago

Just ran into this now. Also, how do we go about resetting a service principal credential? Running 'az ad sp credential reset' returns the non 'sdk-auth' format which does not work with GitHub actions.

jiasli commented 2 years ago

@andersson09, you may manually translate the result of az ad sp credential reset to what GitHub Action requires: clientId, clientSecret, etc.

alexellis commented 2 years ago

We were using the --sdk-auth flag to get a service account to create Virtual Machines on Azure. This flag is now marked as depreciated, but seems to continue to work, but doesn't have the valid permissions at that point.

Could someone point us at the suggested new syntax instead of --sdk-auth?

For reference: https://github.com/inlets/inletsctl/issues/116

jiasli commented 2 years ago

@alexellis,

Could someone point us at the suggested new syntax instead of --sdk-auth?

You may simply use the original output without --sdk-auth. Is there any specific property in --sdk-auth's output that you require?

smarlowucf commented 2 years ago

Hi, I ran into this issue as well. The original output is missing subscription id. Given a service principal is tied to a subscription id and having that id is required to authorize against the Python SDK it's nice to have in the json credential file. Is this something that can be added to the original output before --sdk-auth is removed? Also, the key names all change which makes it harder to support both types. Is there a reason to not use the same key names?

I also ran into the issue with permissions disappearing. Previously a principal was created as a Contributor by default I assume. As it had permissions by default. Now it seems this is required as --role but this change is not communicated.

Additionally it would be nice to set explicit permissions such as:

Compute.Image.Contributor
Storage.Contributor

Is this something that's possible?

smarlowucf commented 2 years ago

I created a separate request related to the missing subscription id https://github.com/Azure/azure-cli/issues/21693

joshuadmatthews commented 2 years ago

@jiasli The format returned without --sdk-auth doesn't work with Github Actions azure/login@v1. Not sure which keys exactly it needs that are missing.

BALAGA-GAYATRI commented 2 years ago

Please refer to this documentation for the above- https://github.com/azure/login#configure-a-service-principal-with-a-secret --sdk-auth still works and you can leverage it for the action.

joshuadmatthews commented 2 years ago

@BALAGA-GAYATRI Thanks for that! As sdk-auth is clearly still useful, why is it being deprecated? Seems like a nice shortcut to have versus building the object manually. I'd sure feel better about using it if the deprecated warning would be removed.

codytipton-hpg commented 2 years ago

Please refer to this documentation for the above- https://github.com/azure/login#configure-a-service-principal-with-a-secret --sdk-auth still works and you can leverage it for the action.

But there is no way to get the desired output for an existing SP. As well, this is impactful not only for the azure/login task, but for any boilerplate which leveraged the secret in a workflow alongside it; e.g., terraform azure module login with key values provided from the same secret. This could have ramifications in the event of need for a credential reset, extending downtime if unaware of the appid -> clientId (and so on) mapping.

joshuadmatthews commented 2 years ago

@codytipton-hpg If you call "az ad sp create-for-rbac" on an existing SP with a scope/role it already has, it will patch it, not changed anything, and return the output needed.

One thing I have found difficult though is that sometimes I get an error message instead of a result, depending on what scopes I apply. If I just apply a management group for instance, then I get an error instead of a result. It seems to need a subscription scope, and even if I include both a MG and a subscription sometimes it still fails.

Also when you do this, it seems the old secret is invalidated so any pipelines using it now need the new credentials to continue working.

asbjornu commented 5 months ago

@jiasli:

Could someone point us at the suggested new syntax instead of --sdk-auth?

You may simply use the original output without --sdk-auth.

No, that doesn't work with the azure/login GitHub Action.

Is there any specific property in --sdk-auth's output that you require?

Yes. As noted in https://github.com/Azure/login/issues/205#issuecomment-1059419886, without the --sdk-auth flag, the azure/login GitHub action will fail with the following error message:

Error: Login failed with Error: Not all parameters are provided in 'creds'. Double-check if all keys are defined in 'creds': 'clientId', 'clientSecret', 'tenantId'.. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.

scottrudy commented 3 months ago

The docs on Quickstart: Deploy Bicep files by using GitHub Actions recommend using --json-auth as opposed to --sdk-auth.

az ad sp create-for-rbac --name {app-name} --role contributor --scopes /subscriptions/{subscription-id}/resourceGroups/exampleRG --json-auth

That said, it generates this warning anyway, so it just adds to the confusion in my opinion.

Option '--sdk-auth' has been deprecated and will be removed in a future release.
onionhammer commented 3 months ago

They need to document using federated credentials better and make that the recommended approach

gautelo commented 1 month ago

@codytipton-hpg If you call "az ad sp create-for-rbac" on an existing SP with a scope/role it already has, it will patch it, not changed anything, and return the output needed.

Also when you do this, it seems the old secret is invalidated so any pipelines using it now need the new credentials to continue working.

Really wish this was documented. I was real confused trying to figure out how to reset and get the new json similar to the originally created output until I found this helpful post.