Configuring a user identity with access policies

Spec fields

instanceTarget

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.

Policies specified inline in accessPolicies take precedence over any conflicting policy for the same resource inherited from an AccessPolicyProfile.

Each entry in resourceRefs references a ProcessGroup by name instead of a literal NiFi path, so a user can be granted access to a flow without first looking up the NiFi-assigned identifier. Cloudera Flow Management Operator for Kubernetes resolves the reference to /process-groups/<status.identifier> at reconcile time.

resourceRefs behaves as follows:

• Each reference resolves to a single NiFi component policy at /process-groups/<id> with the actions requested on the reference.

• The referenced ProcessGroup must target the same Nifi instance as the User.

• If a referenced ProcessGroup does not exist or has not yet been assigned a NiFi identifier, that reference is skipped for the current reconcile; the policies that do resolve are still applied, and the User re-reconciles automatically once the ProcessGroup is ready.

• The CompleteAccessPolicies status condition reports the outcome: True when all references resolved, False with reason ProcessGroupRefNotResolved while a reference is still pending, False with reason ProcessGroupTargetsDifferentNiFi when a reference points at a ProcessGroup on another Nifi (which requires a spec fix), and absent when no resourceRefs are declared. It does not gate UserReady.

• 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.

Examples

Minimal user

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

User with read access to the root process group

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

User with a generated client certificate

Requires the target Nifi to have spec.security.nodeCertGen configured. The operator creates a cert-manager Certificate in the same namespace, using spec.identity as both the CommonName and DNS SAN. The resulting Secret will contain a valid client certificate that can be used to authenticate as the user to the NiFi API.

apiVersion: cfm.cloudera.com/v1alpha1
kind: User
metadata:
  name: alice
spec:
  instanceTarget:
    kind: Nifi
    name: my-nifi
  identity: alice
  certificate:
    generate: true

User with access to a ProcessGroup

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

User with policies from an AccessPolicyProfile

apiVersion: cfm.cloudera.com/v1alpha1
kind: User
metadata:
  name: alice
spec:
  instanceTarget:
    kind: Nifi
    name: my-nifi
  identity: alice
  accessPolicyProfileRef:
    - name: read-only-profile
      namespace: default

Lifecycle

Creation

The operator registers the user in the NiFi API. The NiFi-assigned UUID is written to status.identifier and used by the operator when making additional changes.

Identity rename

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

Access policy changes

On each reconciliation the operator computes the desired policy set by merging inline accessPolicies with any referenced profiles and diffs it against the current NiFi state. Missing policies are added and stale policies are removed. Removing a policy only removes the user from that policy; the policy itself is never deleted.

Deletion

Deleting the User resource removes the user from the NiFi API and from all access policies, then deletes the generated client certificate (if any) 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 UserGroup

Users can be collected into UserGroup resources by direct reference (spec.userRefs). This will assign those users to the relevant user group in NiFi.