Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

target secret functions support #78

Merged
merged 1 commit into from
Apr 23, 2018
Merged

Conversation

ramaro
Copy link
Member

@ramaro ramaro commented Apr 20, 2018

This introduces support for creating a target secret on compile time, if the secret does not already exist.

Target secrets have been introduced a few commits ago and have proven to work well. However when using reclass inventory interpolation for target secret tags, you will be forced to create all of the interpolated target secrets manually as compilation will fail.

To solve this problem, this PR proposes the following new (optional) form of secret tags:

?{gpg:path/to/new_secret|randomstr:32}

Or interpolating ${target_name}:

?{gpg:targets/${target_name}/new_secret|randomstr:16}

If path/to/new_secret does not exist under secrets_path it evaluates randomstr:32, a function supported in this PR, which returns a 32 (as parameterised) byte-log random string generated by https://docs.python.org/3/library/secrets.html#secrets.token_urlsafe and creates the secret with its content.
randomstr can also be evaluated without a parameter and a base64 encoded version of it is also available as randomstrb64 (which mimics the --base64 flag in kapitan secrets command line).

Note that this only supports target secrets and requires the recipients to be set in the inventory for the target being compiled. Once the target secret is created from a function, it will not be recreated.

Copy link
Contributor

@ademariag ademariag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@adrianchifor adrianchifor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ramaro ramaro merged commit 0ba0b65 into kapicorp:master Apr 23, 2018
@epcim
Copy link

epcim commented Apr 25, 2018

Too late, are you aware of NaCL / libsodium instead of gpg?

It's bit more simple and native in python. GPG depends on some setup. I wrote short article about how it works under Salt - http://apealive.net/post/2017-09-salt-nacl-ext-pillar/

@ramaro
Copy link
Member Author

ramaro commented Apr 25, 2018

Well aware of NaCL/libsodium indeed! I did some experimentation a while ago with it, but at the time (and as you state in your article), there was no builtin key management functionality . I do like NaCL/libsodium, but GPG just leaves the key management out of kapitan which we prefer.
However, kapitan secret backend are meant to be plugabble (not at that state yet, but aspirational), so we could easily have a nacl: secret backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants