-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
nixos/gitlab: Add support for secure secrets and more #66274
Conversation
All the work related to systemd should probably be a separate pull request. |
Hm, I was advised that it probably shouldn't, since the gitlab work depends on it, but maybe that's incorrect? I can of course split it into two separate PRs, but the gitlab PR would be broken until the systemd PR is merged, but maybe that's okay? |
I just figured it would be easier to review as two separate things, since it's probably not the same people responsible for reviewing the gitlab and systemd parts. Hopefully somebody more knowledgeable can chip in. |
Yeah, I'm good with either, so if anyone feels strongly that it should be split, I'll split it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First - thank you for tackling this! The module could really use some love. I'm really glad you have taken this on as the end goal is fantastic. I have some opinions on how you're trying to achieve that goal. I hope we can have some productive discussion on the topic.
Thanks for all the great work done here :-) Can you rebase test and rebase this on top of #66621? |
@flokli Thanks! Sorry for the late reply - I've been on vacationing in Berlin for the last week, but I'll be going to cccamp now, so I'll probably have an opportunity to finish this up. I can see that the pr is merged, so I'll just rebase on master. In the meantime I'll push what I have at the moment and anyone interested can have a look. :) |
Hm, just noticed that |
@flokli I rebased on master yesterday and it seems to work well. I've tried just switching to it, and resetting by deleting the db and state, and can't find any obvious issues. :) |
0eef678
to
445f054
Compare
message = "When services.gitlab.databaseHost is customized, services.gitlab.databasePasswordFile must be set!"; | ||
} | ||
{ | ||
assertion = cfg.initialRootPasswordFile != null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't you just remove the default = null
? Then you don't need to create the assertions, same for the assertions below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this because I find the generic message you get when you use an undefined parameter less helpful, but if you want them gone, I can remove them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@talyz thanks for your work based on my comments. I'm approving the database parts of this change. I don't know much about gitlab
on NixOS as I have never run the module (or looked at it much, before this PR) so I'll leave final approval to those more aware than myself.
Given the freeze coming up very quickly I would suggest @globin or @fpletz as the escalation point. @globin are you able to approve and merge this, or specify what changes are required to meet approval?
]; | ||
} "_secret" -> { ".example[1].relevant.secret" = "/path/to/secret"; } | ||
*/ | ||
recursiveGetAttrWithJqPrefix = item: attr: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these two functions, plus the pattern to insert secrets are much more useful for nixos secret management in general, to be hidden in the gitlab module only. Thanks a lot for writing it ❤️
Could this be moved to nixos/lib/utils.nix
, with maybe a line of docs in nixos/doc
? I think other services can make use of that, too…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That being said, this should not block the PR before the feature freeze. If you don't find the time to do it in this PR, it can still be moved there at a later point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem! :) I'll push the changes in a bit, but where in the docs would this fit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flokli I simplified the usage a bit, so that the pattern of using the functions together and outputting the JSON to a file for input is no longer necessary. Does it look okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, somehow I missed the notification. I guess it's fine for now to have it as multi-line comments. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries. :) Okay, great! Yeah, I think it should be in the docs, but I couldn't find a good spot. Maybe there should be a Utility Functions
subsection to the Functions reference
in the nixpkgs manual?
Work around upstream issue NixOS#790 by explicitly referencing the ca-certificates.crt file.
Add support for storing secrets in files outside the nix store, since files in the nix store are world-readable and secrets therefore can't be stored safely there. The old string options are kept, since they can potentially be handy for testing purposes, but their descriptions now state that they shouldn't be used in production. The manual section is updated to use the file options rather than the string options and the tests now test both.
Use the postgresql module to provision a local db (if databaseCreateLocally is true) instead of doing this locally. Switch to using the local unix socket for db connections by default; this is needed since dbs created by the postgresql module only support peer authentication. Instead of running the rake tasks db:schema:load, db:migrate and db:seed_fu, run gitlab:db:configure, which in turn runs these tasks when needed. Solves issue NixOS#53852 for gitlab.
Introduce new functions which allows modules to define options where, if the input is an attrset and the output is JSON, the user can define arbitrary secrets.
Adds the ability to make any parameter specified in extraConfig secret by defining it an attrset containing the attr _secret, which in turn is a path to a file containing the actual secret.
This broke master eval; The set in which it is defined is not recursive. |
Hmm, maybe it got lost in the merge? |
@srhb Oops, yeah, that's my bad - I didn't rebase recently enough. Thanks for fixing it! |
Motivation for this change
Improve the gitlab module in various ways:
This does, as far as I can tell, what the unmaintained #31358 set out to do, and more. I takes a slightly different approach to the problem by mostly using jq to put secrets in place.
To split preStart I implemented support for this in the systemd module rather than hack it into the gitlab module so that other modules can benefit from it. This should solve issues where PermissionsStartOnly cannot be replaced with only tmpfiles.
Needs testing
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @globin @etu @adisbladis @infinisil @lheckemann @nh2 @aanderse