Configuring user groups

Spec fields

instanceTarget

userRefs

Each entry is an object reference to a User resource in the same cluster. The namespace defaults to the UserGroup's own namespace if omitted.

userRefs:
  - name: alice
  - name: bob
    namespace: other-ns

Users that have not yet been reconciled by the User controller (no status.identifier) are silently skipped and will be added on the next reconciliation once their identifier is available.

accessPolicies

Each entry specifies one or more NiFi resource paths and the actions to grant on them.

At least one of resources or resourceRefs must be set. When both are set, the resolved /process-groups/<id> paths are combined with the literal resources into one policy sharing the entry's actions.

The special token /process-groups/root is resolved at runtime to the root process group UUID of the target Nifi instance.

Each entry in resourceRefs references a ProcessGroup by name instead of a literal NiFi path. Cloudera Flow Management Operator for Kubernetes resolves the reference to /process-groups/<status.identifier> at reconcile time.

Behavior matches the User CRD: the referenced ProcessGroup must target the same Nifi instance as the UserGroup; an unresolved reference (the ProcessGroup is missing or not yet ready) is skipped and retried automatically; and the CompleteAccessPolicies condition reports True/False with reason ProcessGroupRefNotResolved (transient) or ProcessGroupTargetsDifferentNiFi (needs a spec fix), and is absent when no resourceRefs are declared. It does not gate UserGroupReady. Cloudera Flow Management Operator for Kubernetes lists unresolved references in the condition message as namespace/name, naming at most 20 per category so the message stays under the Kubernetes 32768-character limit; longer lists end with , and N more.

Status Fields

Examples

Minimal group

A minimal UserGroup with no users or access policies assigned to it.

apiVersion: cfm.cloudera.com/v1alpha1
kind: UserGroup
metadata:
  name: operators
spec:
  instanceTarget:
    kind: Nifi
    name: my-nifi
  identity: operators

Group with members

This group contains users represented by Users alice and bob, both User custom resources in the same namespace as this operators UserGroup. Users alice and bob will be added to the operators UserGroup. This UserGroup does not have any access policies associated with it.

apiVersion: cfm.cloudera.com/v1alpha1
kind: UserGroup
metadata:
  name: operators
spec:
  instanceTarget:
    kind: Nifi
    name: my-nifi
  identity: operators
  userRefs:
    - name: alice
    - name: bob

Group with read access to the root process group

This group contains a single User alice and has read access to the root process group and the UI.

apiVersion: cfm.cloudera.com/v1alpha1
kind: UserGroup
metadata:
  name: readers
spec:
  instanceTarget:
    kind: Nifi
    name: my-nifi
  identity: readers
  userRefs:
    - name: alice
  accessPolicies:
    - resources:
        - /process-groups/root
        - /flow
      actions:
        - read

Group with access to a ProcessGroup

apiVersion: cfm.cloudera.com/v1alpha1
kind: UserGroup
metadata:
  name: flow-operators
spec:
  instanceTarget:
    kind: Nifi
    name: my-nifi
  identity: flow-operators
  accessPolicies:
    - actions:
        - read
        - write
      resourceRefs:
        - kind: ProcessGroup
          name: my-flow

Lifecycle

Creation

The operator registers the group in the NiFi API on the first successful reconciliation. The NiFi-assigned UUID is written to status.identifier and used to identify the group in all subsequent reconciliations.

Identity rename

Updating spec.identity renames the group in the NiFi API on the next reconciliation. The status.identifier is preserved, so NiFi-internal references (policy memberships) are not affected.

Membership changes

On each reconciliation the operator resolves spec.userRefs to NiFi tenant UUIDs via user.status.identifier and calls the NiFi API to set the group's member list. Removing a User from spec.userRefs removes them from the group on the next reconciliation.

Access policy changes

On each reconciliation the operator diffs the desired policy set against the current NiFi state. Missing policies are added and stale policies are removed. Removing a policy only removes the group from that policy; the policy object itself is never deleted from NiFi.

Deletion

Deleting the UserGroup resource removes the group from the NiFi API before releasing the finalizer. If the target Nifi resource is not found at deletion time, the NiFi-side cleanup is skipped and the finalizer is still removed.

Relationship to User

User resources are added to a group by listing them in spec.userRefs. The operator watches User resources and re-reconciles any UserGroup that references them, so membership updates propagate automatically when a User is created or updated.