nixos/openafsServer: automatic extraction of authentication keys from Kerberos 5 service keytab #337101
Conversation
github-actions
bot
added
6.topic: nixos
ofborg
bot
added
10.rebuild-darwin: 0
nessdoor
force-pushed
the
openafs-keytab
branch
from
6a780cb to
3daaa13
Compare
nessdoor
force-pushed
the
openafs-keytab
branch
from
3daaa13 to
f71ba39
Compare
| "|/etc/openafs/server/KeyFileExt" | ||
| ]; | ||
| preStart = '' | ||
| mkdir -m 0755 -p /var/openafs | ||
| ${optionalString (netInfo != null) "cp ${netInfo} /var/openafs/netInfo"} | ||
| ${optionalString useBuCellServDB "cp ${buCellServDB}"} | ||
| '' + lib.optionalString (cfg.authentication.keytab != null) '' | ||
| rm -f /etc/openafs/server/KeyFileExt | ||
| ${asetkeyScript} |
There was a problem hiding this comment.
I just noticed that asetkeyScript never calls asetkey when the configured principal is not in the keytable or the keytable cannot be read. Thus, KeyFileExt never gets created. Please, make preStart fail with a descriptive error message in that case.
nessdoor
force-pushed
the
openafs-keytab
branch
2 times, most recently
from
a06e68e to
3dc63f1
Compare
|
I have modified the AWK script to exit with an error if it could not find any key for the given principal. I also took the liberty of retargeting the release notes for 25.05 instead of 24.11. |
wegank
added
the
12.approvals: 1
wegank
added
the
2.status: merge conflict
nessdoor
force-pushed
the
openafs-keytab
branch
from
3dc63f1 to
64a641b
Compare
Allow users to set a Kerberos 5 keytab from which to automatically extract the authentication keys necessary for AFS operations.
nessdoor
force-pushed
the
openafs-keytab
branch
from
64a641b to
5827cbd
Compare
|
Resolved merge conflict on release notes and |
nessdoor
removed
the
2.status: merge conflict
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/5030 |
wegank
removed
the
12.approvals: 1
Description of changes
Contemporary OpenAFS cells authenticate both users and servers by relying on an existing Kerberos infrastructure. For legacy and compatibility reasons, OpenAFS servers do not use Kerberos 5 service keytabs directly, but instead rely on an OpenAFS-specific keyring located at
/etc/openafs/server/KeyFileExt. This keyring must be filled and managed imperatively by way of theasetkeycommand.To make matters more complicated,
asetkeyexpects the administrator to be aware of the internal numerical encoding used by Kerberos 5 to represent encryption key types, and requires this information to be entered for each key that is added to the keyring viaasetkey add(see asetkey(8)).This PR introduces an automatic mechanism that, given an ordinary Kerberos 5 keytab, parses it for the AFS service keys (identified by a user-configured principal) and automatically constructs a
KeyFileExtfrom these, declaratively and without any further user interaction. The AFS administrator only has to assign the runtime path of the keytab to theservices.openafsServer.authentication.keytaboption and, if needed, indicate the Kerberos 5 principal of the AFS service by setting the value ofservices.openafsServer.authentication.principal.The legacy behavior is retained by default or by explicitly setting
services.openafsServer.authentication.keytab = null.This improvement constitutes a further step towards achieving complete AFS automatic deployment, easing the configuration of machines with volatile root partitions, and implementing automated tests.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.