Support reading IAM token from environment variable

[florisvdg]

We're working on a 1Password Shell Plugin for the ibmcloud CLI, which would add Touch ID authentication for ibmcloud without having secrets on disk.

To fulfill that promise, all we'd need is for ibmcloud to support reading the (short-lived) IAM token from an environment variable, e.g. IBMCLOUD_IAM_TOKEN, so that the ~/.bluemix/config.json file can stay free of secrets.

[Aerex]

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

export IBMCLOUD_API_KEY=$(...)

[florisvdg]

@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.

[Aerex]

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 ?

[florisvdg]

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:

ibm-cloud-cli-sdk/bluemix/configuration/core_config/bx_config.go

Lines 261 to 266 in d415846

	func (c *bxConfig) IAMToken() (token string) {
	c.read(func() {
	token = c.data.IAMToken
	})
	return
	}

[Aerex]

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.

[florisvdg]

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

[florisvdg]

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.

[Aerex]

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.

[florisvdg]

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.