Open garymoon opened 5 years ago
Hi @garymoon, thank you for raising this issue. We will consider this as a feature request and discuss internally.
@jiasli Thank you for the update. Please be sure to consider the implications of unintended credential leakage also. IMO this issue represents a security concern.
In the meantime, for anyone coming across this ticket, I suggest either using the microsoft/azure-cli
docker image and mounting the config dir as tmpfs with --tmpfs [home_dir]/.azure
, or adding AZURE_CONFIG_DIR=/dev/shm/.azure
to your shell if you're on Linux.
Python SDK - Azure Identity also supports environment variables here. Maybe we can implement this independently of Azure Identity integration. Even after the Azure Identity integration, this won't be a breaking change.
Any update on this? It will be super useful for us as well.
We are currently implementing this feature in the Azure Identity Integration process and it will be included in the next Beta release. But we can't provide a solid ETA yet.
Hi @jiasli,
Is there any update or a workaround? We need to use the CLI in a pipeline and do not want to post the password on a command line.
Thanks!
This will be released in the next Beta version which uses MSAL. Hopefully it can satisfy your needs.
Because we dropped Azure Identity in the MSAL migration process (https://github.com/Azure/azure-cli/pull/19853), this feature is temporarily removed from MSAL-based CLI.
Marking it as a Feature Candidate for future planning.
Any updates here? MSAL has been out for quite some time. Other tools, such as terraform, do not require the login call and are therefore more secure in this context.
Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread. :)
This feature aligns with the goal of Azure SDKs:
Any updates on this ?
Any updates on this?
@jiasli - When the enhancement goes live, will it also support OIDC? There are the variables that are used by other providers.
"AZURE_OIDC_REQUEST_TOKEN": "[secret]", "AZURE_OIDC_REQUEST_URL": "https://api.x.com/oidc", "AZURE_OIDC_TOKEN": "[secret]", "AZURE_USE_OIDC": "true"
There are the variables that are used by other providers.
@arunkumar611, could you share more information on these "providers"? I am not able to find any reference to these environment variables on the internet: https://www.bing.com/search?q=AZURE_OIDC_REQUEST_URL , https://www.google.com/search?q=AZURE_OIDC_REQUEST_URL
There are the variables that are used by other providers.
@arunkumar611, could you share more information on these "providers"? I am not able to find any reference to these environment variables on the internet: https://www.bing.com/search?q=AZURE_OIDC_REQUEST_URL , https://www.google.com/search?q=AZURE_OIDC_REQUEST_URL
I think that commenter may have meant ARM_*
instead of AZURE_*
as I do see these 4 on google:
"ARM_OIDC_REQUEST_TOKEN": "[secret]",
"ARM_OIDC_REQUEST_URL": "https://api.x.com/oidc",
"ARM_OIDC_TOKEN": "[secret]",
"ARM_USE_OIDC": "true"
@tspearconquest I thought so too, but proposed PR #27938 implements it with the AZURE_
prefix.
It's not the same variables at all. Those are strictly related to SP auth with secrets whereas this poster asked about OIDC vars but appears to have mistakenly used the AZURE_ prefix. That's all I was trying to say, but thank you. :)
Is your feature request related to a problem? Please describe. I'm concerned that I cannot use the CLI without having my credentials written to disk in the clear.
Describe the solution you'd like I would like the CLI to accept credentials from the environment (e.g.
AZURE_TENANT_ID
,AZURE_CLIENT_ID
,AZURE_CLIENT_SECRET
).Describe alternatives you've considered I've yet to find a way to authenticate that doesn't involve secrets being written to
~/.azure
.Additional context I came across this issue which seems to describe the same thing, but was closed following an apparent misunderstanding. While the AWS CLI does indeed write secrets in the clear to disk when configured via
aws configure
, it also allows for configuration via environment variables.I've also found examples in both the Ruby SDK here, and the Go SDK here where authentication via environment variables is enabled.
This issue is particularly problematic in a dockerized environment where it's common for the home directory to be mapped on the host.