add ldap resource backed by lldap #1055
No reviewers
fediversity/developers
Labels
No labels
ambition
application-offering
ambition
configure-applications
ambition
front-end
ambition/install-applications
ambition
security
ambition
switch-host
ambition
update-applications
ambition
user-management
blocked
component
api-service
component
fediversity-panel
component
nixops4
documentation
points
0
points
0.5
points
1
points
13
points
2
points
21
points
3
points
34
points
5
points
55
points
8
points
infinite
productisation
project-management
question
role
application-developer
role
application-operator
role
hosting-provider
role
maintainer
security
technical debt
testing
type
bug
type
deliverable
type
key-result
type
objective
type
task
type
unclear
type
user-story
user experience
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
fediversity/fediversity!1055
Loading…
Reference in a new issue
No description provided.
Delete branch "kiara/fediversity:lldap"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of #615.
Add an
ldapresource undersrc/resources/ldap/bridging applications to thenixpkgs
ldapcontract, fulfilled by anlldap-backed provider, following thecontracts.sslprecedent for connecting resources to contracts with genuinecross-node evaluation.
details
The resource privileges no provider. The policy carries a `routing` deferredModule (merged verbatim into every eval that imports the provider) that selects the provider in the contract's own terms (`contracts.ldap.defaultProviderName`); the deployment supplies it in `hosts-common.nix`, mirroring `"tls".ssl.routing`. The `lldap-provider.nix` defaults its option to `config.contracts.ldap.providerRequests.lldap` (routing-aware, self-filtering, matching the migrated `hardcoded-ldap.nix` reference) and sets `meta.buildDocsInSandbox = false`; its daemon layer is gated on `options ? systemd` so it is absent under the bare cross-node eval.Consumers read a remote provider's
resultresolved once by a sharedlib.evalModules(ldap/cross-node.nix, via thecrossNodeContractprimitive),rather than importing the provider declaration on every node. This lets
hostbe the lldap node's real deployment FQDN instead of
127.0.0.1: a consumer nodepoints its LDAP client at the directory node. The snakeoil
bindPasswordFileisrendered on each node that binds (consumers + the lldap node) via a shared
snakeoil-bind-password.nix; cross-node secret delivery (agenix/openbao) remainsthe tracked
TODO.Plumb the resource through the data model, mirroring the garage / authelia /
ssl wiring:
hosts-common.nixaddsldaptoancilliaryRequests, registers aper-app
"directory".ldappolicy request (withhost/routing), addsldap.applicationSideto every node, and bakesldap.mainConfigplus allcollected requests onto the
lldapnode;groups/operator.nixadds anlldapancilliary machine;
sharedOptions.nixaddsldap.enable(off by default).Wire Peertube and Mastodon as consumers. Peertube mirrors the
auth-openid-connectOIDC consumer pattern: an offline-packagedpeertube-plugin-auth-ldap(built from a vendoredpackage-lock.jsonviaimportNpmLock.buildNodeModules, pure JS, no network) plus a DB-seeding oneshotthat upserts the
pluginrow with settings derived from the contract result.Mastodon has first-class env-driven LDAP support (
LDAP_*, backed by thebundled
net-ldapgem), so its consumer is purely declarative: non-secretsettings via
services.mastodon.extraConfig, and the bind password rendered atactivation into a root-owned
/runenv file. Both gate login to members of theconsumer's provisioned group via lldap's
memberofattribute. Pixelfed isintentionally skipped (its upstream LDAP support is dormant).
Extend the heavy
apps-tfend-to-end test to cover both consumers: add thelldapprovider node, assert it provisions thepeertube-usersandmastodon-usersgroups, and assert each consumer's running process carries thecontract-derived LDAP settings (the lldap node's FQDN, bind DN, bind-password
path, group-gated filter, snakeoil password). A live cross-node bind is kept at
the wiring level; the
contracts-ldap-lldapbehaviorTest covers the live bind +group lookup on a single node.
99df99368fe363e6e7a8e363e6e7a8012ea9f4f9012ea9f4f9a9269253aaa9269253aa6c287126136c287126138508450fe48508450fe4164df9f13d164df9f13d78015d3fe278015d3fe263e76d1d6463e76d1d64e5ac30dce6307447075329b545b99b29b545b99bf49200799df49200799dec17a3c687ec17a3c68798ef7e09d298ef7e09d25be3a60f8dWIP: addto addldapresource backed bylldapldapresource backed bylldap@ -322,0 +350,4 @@## from `bindPasswordFile` at start.autheliaLdapBackend =ldapResult:import ./authelia-ldap-backend.nix {i wonder if we have a more idiomatic approach to this
@ -226,3 +244,3 @@fi${pkgs.util-linux}/bin/mount --bind "$entry" "$target"donedone < ${closure}/store-pathsTODO update https://github.com/NixOS/nixpkgs/pull/528685 based on these improvements
@ -0,0 +162,4 @@## tmpfiles. Same path, same value, so the daemon + lldap-cli read it## identically. Rendered inline (not via an `imports`, which is invalid in a## `config` block).(lib.optionalAttrs (options ? systemd) (options ? systemdlooks hacky so not sure this seems like the best waythis seems broader than just here, so could be deferred
@ -0,0 +157,4 @@## read below); it no longer *declares* its generation.## Bind-password delivery, behaviorTest fallback (`runDaemon &&## !useVarsBindPassword`). The single-node behaviorTest has no OpenBao server,maybe it should use openbao too (in that single node, ideally reusing our existing code)?
is this like about the spire issue mentioned at our new note in
checks/common/lib.nix?the duration bump in
apps-tfhere seems like it would just adversely impact the overall latency of our feedback cycleed11af5480d112e380fbd112e380fb9aadce0e20265a86492bf3046062b4