Secret Management - Subcommands to interact with Secrets about polykey HOT 8 CLOSED

Rewrote the above for some secret command interaction. @ll-aashwin-ll your opinion?

from polykey.

As for editing something like this might be possible: https://unix.stackexchange.com/a/282384/56970

It seems in general, it might be possible to pipe the output into an editor. Or pipe it to a file, where you then open the file descriptor but delete the file contents (thus you end up with a read/write descriptor). Then pipe that file back into the same command.

Note that one has to be careful with concurrent usage. We should expect similar concurrency issues.

Also note the usage of echo 'abc' >> file. It is also possible to do echo 'abc' >> >(cat > file). But this is more advanced.

from polykey.

I really want to be able to run a polykey command to create a secret, that launches the $EDITOR or $VISUAL and upon saving, pipe the output to the polykey command without leaking any data on disk. Not entirely sure how to achieve this though.

Oh it seems vipe might be the right way to do it. There's also how git launches the editor when you ask to do rebases.

from polykey.

Based on my reading of https://en.wikipedia.org/wiki/Uniform_Resource_Identifier I think this should mean that we can just use pk:/a/b. As well. Or even just pk:a/b. But without the root slash it could mean something else like the current context. I don't think it's specified. There are some good discussion about this here? https://github.com/ipfs/in-web-browsers/blob/master/ADDRESSING.md

from polykey.

polykey secrets ed pk:/a/b

Launches editor for secret, and allows one to save the file.

It works!

tmpfile=$(mktemp /tmp/abc.XXXXXX)
exec {fd}<> "$tmpfile"
rm -f "$tmpfile"
vim "/proc/self/fd/$fd"
cat <&${fd}

The above works in ZSH and Bash using automatic fd allocation.

We would do this inside JS which should be alot more robust.

from polykey.

@robert-cronin Given that you've created the demo already, could we get an update on the status of this issue?

In relation to #3 as well.

from polykey.

The cli now exposes a sub-command for interacting with secrets, the pattern looks like this:

pk secrets <action>

Under this sub command, the user can manipulate secrets with the following commands:

pk secrets ls|list --vault-name <vault-name> # lists the secrets in a particular vault
pk secrets create --vault-name <vault-name> --secret-name <secret-name> --secret-path /path/to/secret # add a secret to a vault
pk secrets get --vault-name <vault-name> --secret-name <secret-name> # get an existing secret

There is still the option of doing away with command options like --vault-name and --secret-name and just doing something like a file path: <vault-name>/<secret-name> but lets just stick with the existing options for now and it can be a convenience later.

The other thing that is useful is environment variables to set default values:

export KEYNODE_PATH=/home/user/Polykey
export DEFAULT_VAULT=Vault1

from polykey.

secrets are now referenced on the CLI with the format <vaultName>:<secretName>
The only thing remaining is to develop the editor for the secrets. I will make a new issue for this

polykey secrets ed pk:/a/b

Launches editor for secret, and allows one to save the file.

It works!

tmpfile=$(mktemp /tmp/abc.XXXXXX)
exec {fd}<> "$tmpfile"
rm -f "$tmpfile"
vim "/proc/self/fd/$fd"
cat <&${fd}

The above works in ZSH and Bash using automatic fd allocation.

We would do this inside JS which should be alot more robust.

from polykey.