Feature request: Support exposing secrets in environment variables

[febus982]

I would like to use the cli to retrieve in real time some secret and expose them as environment variables in the system. (like 1Password developer cli does)

I have managed to get a single password with a mix of bash scripting, sed and jq usage:
export MY_ENV_VAR=$(passbolt get resource --id PUT_RESOURCE_UUID_HERE -j | sed 's/Enter Password://g' | jq -r .password)

This works but it's not a very good experience:

• The password has to be entered for each cli command (I don't want to store it in the config because it's in plain text and easily accessible)
• Using sed to remove the "Enter Password:" prompt is necessary to have only json in the output, but it removes a useful prompt

Allowing to temporarily replace environment variables would be a very secure way of using such secrets locally, without having to have the account password or the secrets persisted anywhere in the local system.

[speatzle]

Hi,

if you wish to skip the Prompt and don't want to save the Password to the Config you could provide the password with userPassword as a Flag or Environment variable.

Saving the Secret to Environment is a great Feature Request but also Requires some Security Considerations.

Unfortunately i have been very busy in recent times and don't think ill have time to work on this in the foreseeable future with lots of Overtime at Work and Passbolt Server API v5 being around the Corner. Supporting v5 will probably require a major rewrite of go-passbolt passbolt/go-passbolt#23 and i am Struggling to make time for that.

However if you decide to make a PR i will review it and merge if it look good.

[febus982]

if you wish to skip the Prompt and don't want to save the Password to the Config you could provide the password with userPassword as a Flag or Environment variable.

It would still be immediately accessible or saved in the history log 🤔

Saving the Secret to Environment is a great Feature Request but also Requires some Security Considerations.

I'm not proposing to persist the secrets permanently to the env vars but to implement the replacement of specific env vars. i.e.

export MY_VAR="passbolt://path/to/passbolt/resource/value"

passbolt exec -- chained_command_or_script

With the cli overriding the MY_VAR variable temporarily only for the nested process.

I would be happy to implement this but unfortunately go is not part of my skills :(

[speatzle]

I'm not proposing to persist the secrets permanently to the env vars but to implement the replacement of specific env vars. i.e.

export MY_VAR="passbolt://path/to/passbolt/resource/value"

passbolt exec -- chained_command_or_script

With the cli overriding the MY_VAR variable temporarily only for the nested process.

In that case we would also have to take Care of overriding all Configuration Environment Variables which are for go-passbolt-cli like the userPassword and others or they will leak to it's subprocesses.

[febus982]

I'm not proposing to persist the secrets permanently to the env vars but to implement the replacement of specific env vars. i.e.

export MY_VAR="passbolt://path/to/passbolt/resource/value"

passbolt exec -- chained_command_or_script

With the cli overriding the MY_VAR variable temporarily only for the nested process.

In that case we would also have to take Care of overriding all Configuration Environment Variables which are for go-passbolt-cli like the userPassword and others or they will leak to it's subprocesses.

Yes, that could be a further improvement.

At the moment, if we configure any environment variable for go-passbolt-cli, any process already can access them.

I see them as different features (which can be done at the same time OFC)

[Nelwhix]

I am currently working on this, will update you as I go

[Nelwhix]

Made the PR