Support reading IAM token from environment variable about ibm-cloud-cli-sdk HOT 9 OPEN

You can use the environment IBM_CLOUD_APIKEY to login to the CLI.

export IBMCLOUD_API_KEY=$(...)

from ibm-cloud-cli-sdk.

@Aerex I'm aware of the ibmcloud login command supporting IBM_CLOUD_APIKEY, but what I'm looking for is environment variable support for (1) every single ibmcloud command and (2) the short-lived access token or IAM token instead of the API key.

from ibm-cloud-cli-sdk.

Ah I see. I dont think we support commands to use a short lived token per command. I think that is outside the design of the CLI. Thoughts @steveclay @tonystarkjr3 ?

from ibm-cloud-cli-sdk.

Would be a nice low-lift addition that would enable ibmcloud usage without having plaintext secrets on disk.

Environment variable support for short-lived secrets is a pretty common pattern for other cloud vendor CLIs too, e.g. aws supporting AWS_SESSION_TOKEN.

The desired effect for us could already be achieved by checking os.Getenv("IBMCLOUD_IAM_TOKEN") in this function:

from ibm-cloud-cli-sdk.

but what I'm looking for is environment variable support for (1) every single ibmcloud command and (2) the short-lived access token or IAM token instead of the API key.

What is the use case for option 1?

For option 2, the CLI doesn't manage auth sessions so a short-lived access token and a API token will be consumed in the same way. You may need to speak with the iam team on that.

from ibm-cloud-cli-sdk.

Interesting: The official IBM Cloud Terraform provider already supports the IBMCLOUD_IAM_TOKEN environment variable!

https://github.com/IBM-Cloud/terraform-provider-ibm/blob/40a3bcb930463ddae140fbdc9da588e0e0ec5d13/ibm/provider/provider.go#L195

from ibm-cloud-cli-sdk.

What is the use case for option 1?

@Aerex To be able to authenticate to every command without requiring ibmcloud login, preventing any plaintext credentials on disk.

For option 2, the CLI doesn't manage auth sessions so a short-lived access token and a API token will be consumed in the same way. You may need to speak with the iam team on that.

If the IBM Cloud API can handle long-lived API keys directly without requiring an intermediate short-lived IAM token, then that would also solve my use case. As long as every command then supports the IBMCLOUD_API_KEY environment variable, that is.

from ibm-cloud-cli-sdk.

If the IBM Cloud API can handle long-lived API keys directly without requiring an intermediate short-lived IAM token, then that would also solve my use case

Have you looked into increaesing the session time? I understand wanting a long-lived API key but I think it would go against the design of the IAM tokens. I think you can configure different clients (UI vs CLI) to have different sessions timeouts.

from ibm-cloud-cli-sdk.

To be clear: my preference would still be using the short-lived IAM token, and having ibmcloud read that from IBMCLOUD_IAM_TOKEN exactly like your Terraform provider already does today.

I was just pointing out that the IBM API key route would be an acceptable workaround/fallback from my side if that's already possible.

from ibm-cloud-cli-sdk.