-
Notifications
You must be signed in to change notification settings - Fork 88
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
handling secrets with gitlabform #57
Comments
Hi @weakcamel , thank you for this report. Frankly I have not thought about adding secure secrets handling to gitlabform yet. At Egnyte we deploy gitlabform using Puppet, so we keep its config in a git repo, with all the values that are secret encrypted using asymmetric encryption - https://github.com/voxpupuli/hiera-eyaml. So on the machine which runs gitlabform once a day the config file is deployed in unencrypted form. This allows us to give developers access to the config repo and the public key so they can add MRs to add their new secrets encrypted. It is not perfect, but it's is safe enough for us thanks to other means of security that we use. I think you can use hiera-eyaml even without using Puppet as it has cli to generate encryption keys, encrypt single value, edit encrypted file, decrypt single value, decrypt whole file - all the features to deploy the flow similar to ours. There is also https://github.com/mozilla/sops that seems to work in a similar way and has more features, but I have not use it myself. Of course, as always, any PRs to gitlabform adding securing of the secrets into it are welcome too! |
For your information (and for the record): for now I've worked around that with Jinja2 templates. Once peopledoc/vault-cli#113 is finished, I'm going to also break down the I may still look at adding secret support (or maybe Jinja2 support?) to Gitlabform at some point, but probably not just yet. |
I had the same problem, ended up just using sed in the gitlab-ci.yml to replace like so: |
How about adding support for automatic replacement of some strings with environment variables + changing logging code to not print any values with verbosity level up to „verbose” (they would still be printed with „debug” on though). This would allow setting them as secrets in GitLab project, setting them from Vault in a pre-script etc. and seems easy to implement. What do you think? |
...or we could add built-in Jinja2 support to automatically pre-process the while config with built-in code similar to answers for https://stackoverflow.com/q/25862071/2693875 to be able to reference env variables anywhere. This would generalize @mkjmdski ’s code for Jinja2 support for file contents and setting GitLab URL and token from env variables. |
...and this could remove uglyness of group, project and usernames used in the integration tests being both hardcoded in provided configs as well as in variables for all the rest of the code. With Jinja2 and env variables support we could just set the variables as env variables and then reference them in the configs. We could even randomize thise entities names to make the tests run on new entities each time and not run into problems with GitLab having a delay with actually deleting resources, to which you run into when you have static resource names. I am starting to love this idea! 😍 |
Yes, an ability to grab values from environment or to pass arbitrary Jinja variables on via CLI to gitlabform (e. g. The change in logging also sounds like a reasonable, simple way to hide the secrets. |
Using Jinja2 templating everywhere would also be a nice workaround for YAML limitation: it can have anchor/alias for a mapping/object, but not for a sequence. We would just define the sequence as a variable and then put it into places where we want it using Jinga2 tags. |
We wrapped a few tools together into a CLI and threw it into a docker container: The tools include:
Feel free to make your own wrapper based on ours, or contribute. MRs welcome! |
GitlabForm can be succesfully used to provision Gitlab projects with secrets, like passwords, API keys etc.
This is extremely helpful. It also means that with the current design, those secrets need to be hardcoded inside the
config.yml
fileIt be great if sensitive data could be passed from external sources. Reasons:
At the moment the only workaround for that that I can think of would be to keep have
config.yml
file as a template to be filled in at runtime (e.g. with https://pypi.org/project/j2cli/ or https://pypi.org/project/jinja2-vault/). This however:{{ project }}
/{{ group }}
).Do you ( @gdubicki - project owner) have any plans (or even just opinions) on such functionality?
The text was updated successfully, but these errors were encountered: