Pluggable authentication #558

New issue

Open

opened 2024-10-24 10:02:46 +00:00 by kfearsoff · 4 comments

kfearsoff commented

2024-10-24 10:02:46 +00:00

Member

We need to have pluggable authentication. It should be extensible, and it should work for builds, so that it's possible to fetch resources from private registries.

There is an upstream PR that implements this already, but it is a very complex approach. It extends the client<->daemon communication to relegate authentication (and so, the control flow) to the client when needed. It requires a protocol version bump. While it addresses the primary usecase, it also sets us on the part of having to vendor every auth scheme on Earth in the Nix daemon and CLI implementations.

A better approach seems to be client-side building. It seems to play nicely with already existing derivation attributes like preferLocalBuild = true and allowSubstitutes = false. It also seems to be a nicer abstraction for no-daemon/daemon modes of working.

#272 - AWS auth is hell. For that reason, we bundle aws-sdk-cpp, which explodes build times and harms LTO. If we can have pluggable authentication - we can nuke all of it, and happily let the user do any kind of auth they want however they want (such as with AWS CLI or aws-vault)
#254 - netrc is kind of a gross hack. We might be able to pretty much nuke it from code without even breaking compat
CppNix PR #10567 - we don't yet support git remote helpers, because we vendor fetching so heavily. A major usecase for them is specific, sometimes very esoteric, authentication; solving authentication is necessary for this support

We need to have pluggable authentication. It should be extensible, and it should work for builds, so that it's possible to fetch resources from private registries. There is an [upstream PR](https://github.com/NixOS/nix/pull/9857) that implements this already, but it is a very complex approach. It extends the client<->daemon communication to relegate authentication (and so, the control flow) to the client when needed. It requires a protocol version bump. While it addresses the primary usecase, it also sets us on the part of having to vendor every auth scheme on Earth in the Nix daemon and CLI implementations. A better approach seems to be [client-side building](https://github.com/NixOS/nix/issues/9344). It seems to play nicely with already existing [derivation attributes](https://nix.dev/manual/nix/2.18/language/advanced-attributes) like `preferLocalBuild = true` and `allowSubstitutes = false`. It also seems to be a nicer abstraction for no-daemon/daemon modes of working. ## Related Issues #272 - AWS auth is hell. For that reason, we bundle aws-sdk-cpp, which explodes build times and harms LTO. If we can have pluggable authentication - we can nuke all of it, and happily let the user do any kind of auth they want however they want (such as with AWS CLI or `aws-vault`) #254 - netrc is kind of a gross hack. We might be able to pretty much nuke it from code without even breaking compat [CppNix PR #10567](https://github.com/NixOS/nix/pull/10567) - we don't yet support git remote helpers, because we vendor fetching so heavily. A major usecase for them is specific, sometimes very esoteric, authentication; solving authentication is necessary for this support

jade added the

E/requires rearchitecture

label 2024-11-10 02:55:24 +00:00

jade commented

2024-11-10 02:55:39 +00:00

Owner

impossible without protocol rewrite. postponed until that happens.

jade added the

Status

postponed

label 2024-11-10 02:55:46 +00:00

szlend commented

2024-11-23 11:11:52 +00:00

Would porting configurable-impure-env from Nix 2.19 be a reasonable short-term solution? It would allow passing impure env variables to FOD builders for trusted users, so we'd no longer need secrets in plain text on the filesystem.

Obviously passing secrets to all FODs is not ideal and client-side building would be preferable, but I feel like this could be a quick win meanwhile.

Example use:

NIX_CONIFG="impure-env = TOKEN=$(fetch-token-from-key-store)" nix build .#foo

^ You can then alias this and use when necessary.

Would porting `configurable-impure-env` from Nix 2.19 be a reasonable short-term solution? It would allow passing impure env variables to FOD builders for trusted users, so we'd no longer need secrets in plain text on the filesystem. Obviously passing secrets to all FODs is not ideal and client-side building would be preferable, but I feel like this could be a quick win meanwhile. Example use: ``` NIX_CONIFG="impure-env = TOKEN=$(fetch-token-from-key-store)" nix build .#foo ``` ^ You can then `alias` this and use when necessary.

jade commented

2024-11-26 07:01:58 +00:00

Owner

Yes, in principle. It doesn't look too evil, it does not require protocol changes to implement, it contains almost no code, and does not seem like it should have any weird interactions with other features. It is gated behind an experimental feature; I do wonder why that is, and the gh milestone gives no such indication: https://github.com/NixOS/nix/milestone/37.

szlend commented

2024-11-26 08:11:46 +00:00

Yeah, not sure why. I've been using it for a few weeks testing the nixpkgs Nix 2.24 bump and got pretty excited to be able to get rid of all filesystem credentials.

There was one small bug fix: https://github.com/NixOS/nix/pull/10049
Open discussion on whether this feature should require trusted-users: https://github.com/NixOS/nix/issues/10472
Notes from the Nix team on how this feature could be easier to use, with no consensus on a solution: https://github.com/NixOS/nix/pull/8830#issuecomment-1744032466

It probably wouldn't need trusted-users if the daemon had to opt into which variables clients can pass to it. So you can't just override daemon's own impure vars like HTTP_PROXY or something.

Yeah, not sure why. I've been using it for a few weeks testing the nixpkgs Nix 2.24 bump and got pretty excited to be able to get rid of all filesystem credentials. - There was one small bug fix: https://github.com/NixOS/nix/pull/10049 - Open discussion on whether this feature should require `trusted-users`: https://github.com/NixOS/nix/issues/10472 - Notes from the Nix team on how this feature could be easier to use, with no consensus on a solution: https://github.com/NixOS/nix/pull/8830#issuecomment-1744032466 It probably wouldn't need `trusted-users` if the daemon had to opt into which variables clients can pass to it. So you can't just override daemon's own impure vars like `HTTP_PROXY` or something.