Security

TLS

NiFi sets up TLS encryption for the http endpoints that serve the UI. By default, this interface is secured using certificates generated to work with the default SecretClass tls.

Nifi can be configured to use a different SecretClass as shown below:

apiVersion: nifi.stackable.tech/v1alpha1
kind: NifiCluster
spec:
  # ...
  clusterConfig:
    tls:
      serverSecretClass: non-default-secret-class (1)

1	The name of the SecretClass used for certificates for the NiFi UI.

Authentication

Every user has to authenticate themselves before using NiFI. There are multiple options to set up the authentication of users. All authentication related parameters are configured under spec.clusterConfig.authentication.

Single user

The Single user allows the creation of one admin user for NiFi. This is a rudimentary authentication method to quickly test and log in to the canvas. However, due to it being a single user with all rights, this is not recommended in production.

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: simple-nifi-users (1)
spec:
  provider:
    static:
      userCredentialsSecret:
        name: nifi-admin-credentials (2)

1	The name of the AuthenticationClass referenced in the NiFi cluster.
2	The name of the Secret containing the admin credentials.

apiVersion: v1
kind: Secret
metadata:
  name: nifi-admin-credentials (1)
stringData:
  admin: admin (2)
  bob: bob (3)

1	The name of the Secret containing the admin user credentials.
2	The user and password combination of the admin user. The username must be "admin" and cannot be changed. The NiFi Pods will not start if they cannot mount the "admin" entry from the Secret. The password can be adapted.
3	The Secret maybe used by other products of the Stackable Data Platform that allow more than one user. The Stackable operator for Apache NiFi will ignore all users except for "admin".

spec:
  clusterConfig:
    authentication:
      - authenticationClass: simple-nifi-users (1)

1	The reference to an AuthenticationClass. NiFi only supports one authentication mechanism at a time.

LDAP

NiFi supports authentication of users against an LDAP server. This requires setting up an AuthenticationClass for the LDAP server. The AuthenticationClass is then referenced in the NifiCluster resource as follows:

apiVersion: nifi.stackable.tech/v1alpha1
kind: NifiCluster
metadata:
  name: test-nifi
spec:
  clusterConfig:
    authentication:
      - authenticationClass: ldap (1)

1	The reference to an AuthenticationClass called `ldap`

You can follow the Authentication with OpenLDAP tutorial to learn how to set up an AuthenticationClass for an LDAP server, as well as consulting the AuthenticationClass reference .

OIDC

NiFi supports authentication of users against an OIDC provider. This requires setting up an AuthenticationClass for the OIDC provider and specifying a Secret containing the OIDC client id and client secret as part of the NiFi configuration. The AuthenticationClass and the OIDC client credentials Secret are then referenced in the NifiCluster resource:

apiVersion: nifi.stackable.tech/v1alpha1
kind: NifiCluster
metadata:
  name: test-nifi
spec:
  clusterConfig:
    authentication:
      - authenticationClass: oidc (1)
        oidc:
          clientCredentialsSecret: nifi-oidc-client (2)

1	The reference to an AuthenticationClass called `oidc`
2	The reference to an existing Secret called `nifi-oidc-client`

apiVersion: authentication.stackable.tech/v1alpha1
kind: AuthenticationClass
metadata:
  name: oidc
spec:
  provider:
    oidc:
      hostname: keycloak.example.com
      rootPath: /realms/test/ (1)
      principalClaim: preferred_username
      scopes:
        - openid
        - email
        - profile
      port: 8080
      tls: null
  [...]

1	A trailing slash in `rootPath` is necessary.

apiVersion: v1
kind: Secret
metadata:
  name: nifi-oidc-client
stringData:
  clientId: <client-id>
  clientSecret: <client-secret>

Authorization

NiFi supports multiple authorization methods, the available authorization methods depend on the chosen authentication method.

Authorization is not fully implemented by the Stackable Operator for Apache NiFi.

Single user

With this authorization method, a single user has administrator capabilities.

LDAP

The operator uses the FileUserGroupProvider and FileAccessPolicyProvider to bind the LDAP user to the NiFi administrator group. This user is then able to create and modify groups and policies in the web interface. These changes local to the Pod running NiFi and are not persistent.

OIDC

With this authorization method, all authenticated users have administrator capabilities.

An admin user with an auto-generated password is created that can access the NiFi API. The password for this user is stored in a Kubernetes Secret called <nifi-name>-oidc-admin-password.

Encrypting sensitive properties on disk

Some flows require storing a sensitive property like a password or access token, which is then stored on disk. NiFi encrypts these properties in flow files.

The sensitive property encryption is configured using the properties keySecret, autoGenerate and algorithm in the spec.clusterConfig.sensitiveProperties configuration section of the NifiCluster resource.

The keySecret configures the name of the Secret object that holds the encryption key; it is required to specify a Secret name. The Secret needs to contain the key as a value to the nifiSensitivePropsKey key. You can either specify a key yourself - in which case the key needs to be at least 12 characters long - or just specify the name of the Secret and set autoGenerate to true (the default is false). If autoGenerate is false and no Secret with the given name in keySecret is found, the operator raises an error.

The algorithm property configures the encryption algorithm used to encrypt the sensitive properties. Consult the reference documentation for a list of supported algorithms.

Autogenerated key example

Let the operator generate a Secret with the name nifi-sensitive-property-key:

sensitiveProperties:
  keySecret: nifi-sensitive-property-key
  autoGenerate: true

Custom key and encryption algorithm example

Create the Secret yourself:

apiVersion: v1
kind: Secret
metadata:
  name: nifi-sensitive-properties-key
stringData:
  nifiSensitivePropsKey: my-encryption-key

Configure the Secret and a different encryption algrithm:

sensitiveProperties:
  keySecret: nifi-sensitive-property-key
  algorithm: nifiArgon2AesGcm256

Host Header Check

NiFi checks the host header of incoming requests and rejects them if they are passing through a proxy that is not on an allow-list configured in the nifi.web.proxy.host property.

A patch applied during the build of the SDP container image for NiFi allows turning off this check by adding nifi.web.proxy.host=* to the properties. The Host header check for NiFi clusters created by the operator is disabled by default but can be enabled in the NiFi configuration. In this case the list of allowed hosts defaults to Kubernetes Services used by NiFi and can be extended with custom entries.

spec:
  clusterConfig:
    hostHeaderCheck:
      allowAll: false
      additionalAllowedHosts:
      - example.com:1234