Membership Reconciler

[lukidoescode]

Motivation

The LldapMembership CRD represents a single user-to-group edge. This granular design is Kyverno-friendly and allows fine-grained RBAC over who can assign users to groups.

Definition of Done

• On Apply:
  1. Resolve the userName field to the lldap user ID (lookup via LldapUser CRD status or query lldap directly).
  2. Resolve the groupName field to the lldap group ID (lookup via LldapGroup CRD status).
  3. If both exist: call addUserToGroup(userId, groupId). This is idempotent in lldap (adding an existing membership is a no-op).
  4. If either doesn't exist yet: set condition Pending with a message, requeue after 10s. This handles ordering issues where the membership is created before the user or group.
  5. Update status with conditions and observedGeneration.
• On Cleanup:
  1. Call removeUserFromGroup(userId, groupId).
  2. If the user or group no longer exists in lldap, treat as success.
• Edge cases:
  • User CRD deleted while membership still exists: membership reconciler detects user gone, cleanup succeeds trivially.
  • Group CRD deleted while membership still exists: same handling.
  • Membership for built-in group (e.g., assigning a user to lldap_admin): works normally since the virtual LldapGroup CRD provides the groupId.
  • Duplicate memberships: if two LldapMembership CRDs reference the same user- group pair (same namespace), the second one should detect the duplicate and set a Conflict condition with a message identifying the existing LldapMembership CRD. The lldap API call is idempotent, but deletion of either CRD would remove the membership for both.
• Emit events for membership add/remove/error.
• Documentation: Update the CRD Reference with LldapMembership usage. Add examples showing Kyverno integration patterns (e.g., auto-assign new users to a default group). Document dependency ordering behavior.

Technical Details

• Use Server-Side Apply for all status patches (see Ticket Reconciliation Robustness and Startup Behavior #15).
• Finalizer name: lldap-operator.lukidoescode.com/membership-cleanup
• Resolution strategy: first try to read the referenced LldapUser/LldapGroup CRD in the same namespace and extract the lldap ID from its status. If the CRD exists but status has no ID yet (it hasn't been reconciled), requeue. If the CRD doesn't exist, set error condition.
• The membership reconciler should watches() LldapUser and LldapGroup resources so that when a user/group is successfully reconciled (gets an ID), pending memberships are re-triggered.
• lldap API note: addUserToGroup takes userId: String and groupId: Int. Despite the name, userId is the username string in lldap, not a numeric ID or UUID. removeUserFromGroup uses the same signature.

[lukidoescode]

Cross-reference from #4: a stateless cross-reference matcher landed in lldap-operator-reconciler::validation.

validate_membership_references takes a MembershipReference<'_> plus iterators of UserCandidate<'_> / GroupCandidate<'_> — small borrowed structs carrying (namespace, instance, identifier). It matches by username / display_name within the same namespace and same instance label value, and returns MembershipValidationError::{UserNotFound, GroupNotFound} otherwise. No kube client, no ObjectMeta, no I/O.

When implementing this reconciler:

• The stateful part (listing user/group CRDs from the cache) and the adapter part (pulling namespace + the lldap-operator.lukidoescode.com/lldap-instance label off ObjectMeta, plus the relevant spec field, into candidate structs) are the caller's responsibility.
• The DoD here calls for Pending + requeue on missing references; translate UserNotFound / GroupNotFound into that condition at the call site rather than treating them as fatal.