Currently, there are a few things I'm unsure about with regards to my implementation.

1. IBM Cloud does create a configuration file at ~/.bluemix/config.json when the CLI is set up, however, from what I know there's no mechanism through which API keys are ever automatically saved to this config file through the IBM CLI. I wrote a file importer so that if a user were to manually enter their API key in ~/.bluemix/config.json with APIKey as the key, it could be imported into 1Password. However, if this is too much of a stretch I could remove the file importer altogether.
2. With the current implementation, in order to authenticate you need to run ibmcloud login. If you were to run ibmcloud account list before authenticating with ibmcloud login first, for example, the command would fail. If the user isn't authenticated and they run a command besides ibmcloud login, do we want to run ibmcloud login under the hood first so that the command doesn't fail? If this is the desired behaviour, could I get some guidance on how to implement this?

IBM Cloud does create a configuration file at ~/.bluemix/config.json when the CLI is set up, however, from what I know there's no mechanism through which API keys are ever automatically saved to this config file through the IBM CLI. I wrote a file importer so that if a user were to manually enter their API key in ~/.bluemix/config.json with APIKey as the key, it could be imported into 1Password. However, if this is too much of a stretch I could remove the file importer altogether.

Does the IBM CLI read the API key from said config file? I'm asking because that would be a reason for users to manually add it.

With the current implementation, in order to authenticate you need to run ibmcloud login. If you were to run ibmcloud account list before authenticating with ibmcloud login first, for example, the command would fail. If the user isn't authenticated and they run a command besides ibmcloud login, do we want to run ibmcloud login under the hood first so that the command doesn't fail? If this is the desired behaviour, could I get some guidance on how to implement this?

Your current implementation is a great first version, that's already super valuable. It allows users to remove the API key from plaintext on disk, and instead load it through 1Password when and where needed. Not having to run ibmcloud login first would be a great additional improvement, but it shouldn't block this current implementation from moving forward already.

Does the IBM CLI read the API key from said config file? I'm asking because that would be a reason for users to manually add it.

@SimonBarendse No there aren't any instances where the CLI reads the API key directly from the config file from what I know. The CLI stores a bearer and refresh token in the config file to authenticate, which may contain information extracted or derived from the API key, but it never reads an API key directly.

After some more thought, I feel like removing the file importer may be the right choice. Most likely, the user would be storing their API key in some other unknown location on their local disk since there isn't even a recommended location that IBM suggests users keep their API key. So in most cases, scanning the config file for an API key would probably not be useful. Can I get your thoughts on this @SimonBarendse?

Added one more small change to skip auth through 1Password when user runs ibmcloud logout, to avoid the edge case where a user runs ibmcloud logout in a new terminal session and needs to authenticate through 1Password only to be logged out right away.

If the way to pass the key is through an envvar and not through the config file, the envvar importer will be sufficient.

Most likely users are storing the key in their ~/.zshrc or equivalent to set the environment.

So the current approach we are taking in this PR will not work. Last time I checked we were waiting on IBM's team to introduce support for an env var in ibmcloud. The reason why we can't use a file provisioner here is because the ibmcloud cli keeps writing back to the config file and this will block our FIFO indeterminately. Since none of this issue have an ETA on their solutions, I will go ahead and close this PR for the time being.