Jannik Rebmann

Posted on Nov 23, 2023 • Edited on Jun 5 • Originally published at jannikrebmann.de

Setup a secure Apache NiFi cluster in Kubernetes

#kubernetes #productivity #opensource #datascience

This article provides a detailed, step-by-step guide on setting up a secure Apache NiFi cluster with a NiFi Registry in Kubernetes, featuring the following capabilities:

NiFi and the NiFi Registry are secured via https.
Authentication of all services is realized via OpenId Connect (OIDC).
The internal communication between the nodes is encrypted.
The communication between the cluster and the NiFi Registry is encrypted and authenticated.

Motivation

In a world where ChatGPT is bringing artificial intelligence into our everyday lives, data integration becomes a key challenge. Ensuring that AI systems receive the right data at the right time will be crucial.

This article addresses this challenge using Apache NiFi, a proven data integration system that has been effectively solving data integration problems long before the AI revolution.

However, I do have one major criticism of Apache NiFi: The barrier to entry is relatively high. The process of setting up a secure cluster of nodes and connecting it to a secure NiFi registry can be time-consuming, especially for those new to the system.

That is why I have decided to write this article to help everyone get started with this excellent system. I promise it will be worth it!

Prerequisites

You need a Linux system (I used Ubuntu 22.04.3 LTS) with the following software installed:

docker: Platform and runtime environment for container virtualization.
minikube: A local Kubernetes environment for development.
helm: A package manager for organizing software and systems developed for Kubernetes.

1. Preparations

The use of minikube is very simple. With just one command, a local Kubernetes is started, which offers all the features of Kubernetes except for the high scalability:

$> minikube config set cpus 4

$> minikube config set memory 8184

$> minikube start

1.1 Enable ingress in minikube

To be able to access the Apache NiFi services via URL later on, we still need to enable the ingress controller of minikube.

$> minikube addons enable ingress

1.2 Integrate `kubectl` for minikube

Another useful thing about minikube is that it always comes with a matching kubectl client. This can be accessed with the command minikube kubectl and behaves identically to a standalone installation of kubectl. Therefore it is recommended to provide this command with an alias and enable auto-completion for kubectl.

$> echo 'alias kubectl="minikube kubectl --"' >> ~/.bashrc

$> echo 'source <(kubectl completion bash)' >> ~/.bashrc

$> source ~/.bashrc

After all the above steps are done, everything is set up to use kubectl against minikube. To test kubectl, you can run the following command (you can use auto-completion with Tab) :

$> kubectl version -o yaml

1.3 Install cert-manager in minikube

The cert-manager is a framework to organize X.509 certificates within a Kubernetes cluster and simplifies the process of obtaining, renewing and using certificates.

To secure the NiFi cluster from unauthorized access and to encrypt the communication between the NiFi nodes, we use the cert-manager to issue us these certificates.

The installation of the cert-manager can be done with a single command:

$> kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml

1.4 Map NiFi domains to minikube

While the ingress controller handles URL mapping within the Kubernetes cluster, it's important to note that the URL must initially reach minikube. After successfully configuring the setup, you will be able to access the following two addresses via your browser:

nifi.example.org
nifi-registry.example.org

You can use the following command to add both mappings to the /etc/hosts file:

$> cat << EOF | sudo tee -a /etc/hosts
# Map nifi.example.org and nifi-registry.example.org to minikube ip
`minikube ip`   nifi.example.org
`minikube ip`   nifi-registry.example.org
EOF

1.5 Register OpenID connect (OIDC) clients

OpenID Connect (OIDC) is a protocol for secure user authentication and information sharing, where the provider performs authentication on behalf of the application. OIDC has become a standard and is offered by many large platform providers such as Google, PayPal but also GitLab.
Moreover, OIDC is gaining popularity within organizations. Solutions such as Keycloak or Authelia offer a convenient ways to provide OpenId Connect on the basis of e.g. LDAP.

Both Apache NiFi and the Apache NiFi Registry support OpenID Connect to authenticate their users. This means we have to register two clients with a OIDC provider.

For this article I will use GitLab as OIDC provider. However, any other platform can be used as well. The only thing that changes is actually the domain name. The required information remains the same.

For GitLab the OIDC client registration is very easy. Just open your GitLab profile and create two new Applications:

NiFi OIDC Client:

Name: NiFi
Redirect URI: https://nifi.example.org/nifi-api/access/oidc/callback
Scopes:
- openid
- email

NiFi Registry OIDC Client:

Name: NiFi Registry
Redirect URI: https://nifi-registry.example.org/nifi-registry-api/access/oidc/callback
Scopes:
- openid
- email

For both registrations you need to save the following information for later integration into our NiFi services:

Name	Placeholder	Example
Discovery URL	`<discovery_url>`	https://gitlab.com/.well-known/openid-configuration
Application ID	`<application_id>`	c9515c774fa1036cbcae5de455a23cc6ca7da54109a858f5b2c6869a89d40f08
Secret	`<secret>`	90b45e16b759fa097461917e7ef3df2c79916b548e1dc44f8d1c2b2c8a8c5537
GitLab email	`<registered_email>`	john.doe@example.org

"The OIDC standard uses a discovery endpoint (discovery_url) to supply clients with configuration information from the OIDC server. This endpoint URL consistently ends with .well-known/openid-configuration but might have a unique prefix path depending on the provider.

For instance, Keycloak includes additional realm information in its discovery URL: https://{keycloakhost}:{keycloakport}/realms/{realm}/.well-known/openid-configuration.

2. Setup an Apache NiFi cluster

One major advantage of Kubernetes standardization is the availability of numerous preconfigured software packages, including entire software systems in the form of helm packages. Fortunately, there's a helm chart for Apache NiFi, simplifying the process of setting up a entire cluster.

You can access this package through a public helm repository, which you can conveniently add to your local helm chart sources using these commands:

$> helm repo add cetic https://cetic.github.io/helm-charts

$> helm repo update

This helm chart provides a wide range of configuration options, all documented in the associated GitHub project helm-nifi.

The following configuration deploys a secure NiFi cluster with two nodes and OIDC authentication (the placeholders <application_id>, <secret> and <registered_email> are defined in section 1.5):

fullnameOverride: nifi
image:
  tag: 1.18.0
replicaCount: 2
properties:
  sensitiveKey: changeMechangeMe
  isNode: true
  webProxyHost: nifi.example.org
certManager:
  enabled: true
  ## Uncomment the next two lines only if you have
  ## installed the NiFi registry
  # caSecrets:
  #   - nifi-registry-ca
auth:
  admin: <registered_email>
  oidc:
    enabled: true
    discoveryUrl: https://gitlab.com/.well-known/openid-configuration
    clientId: <application_id>
    clientSecret: <secret>
    claimIdentifyingUser: email
    admin: <registered_email>
persistence:
  enabled: true
  subPath:
    enabled: true
ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/app-root: /nifi
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/affinity-mode: persistent
    nginx.ingress.kubernetes.io/affinity: "cookie"
    cert-manager.io/issuer: "nifi-ca"
  hosts:
    - nifi.example.org
  tls:
    - hosts:
        - nifi.example.org
      secretName: nifi-example-crt-secret

Now you can deploy the Apache NiFi cluster with the given configuration file nifi_values.yaml:

$> helm upgrade -i -f nifi_values.yaml nifi cetic/nifi

Open your browser and enter the address https://nifi.example.org.

Depending on your PC and internet connection, the download of all Docker images and the startup of the entire system can take several minutes.

You can check the current progress by entering:
$> kubectl get pods
If all pods are in the READY state, you should be able to access the service via the browser.

You may have to accept your browser's certificate warning.

3. Setup an Apache NiFi Registry

As with the installation of the NiFi cluster, there is a helm package for the NiFi registry. You need to add it to your local helm repository:

$> helm repo add dysnix https://dysnix.github.io/charts/

$> helm repo update

The following configuration deploys a secure NiFi registry with OIDC authentication (the placeholders <application_id>, <secret> and <registered_email> are defined in section 1.5):

fullnameOverride: nifi-registry
image:
  tag: 1.18.0
security:
  enabled: true
  needClientAuth: false
  admin: <registered_email>
certManager:
  enabled: true
  replaceDefaultTrustStore: false
  caSecrets:
    - nifi-ca
  additionalDnsNames:
    - nifi-registry
oidc:
  enabled: true
  discoveryUrl: https://gitlab.com/.well-known/openid-configuration
  clientId: <application_id>
  clientSecret: <secret>
  claimIdentifyingUser: email
  admin: <registered_email>
persistence:
  enabled: true
ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/app-root: /nifi-registry
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    cert-manager.io/issuer: " nifi-registry-ca"
  hosts:
    - host: nifi-registry.example.org
      paths:
        - path: /
          pathType: Prefix
  tls:
    - hosts:
        - nifi-registry.example.org
      secretName: nifi-reistry-example-crt-secret

Now you can deploy the Apache NiFi Registry with the given configuration file nifi_reg_values.yaml:

$> helm upgrade -i -f nifi_reg_values.yaml nifi-reg dysnix/nifi-registry

Open your browser and enter the address https://nifi-registry.example.org.

4. Configure Apache NiFi

Since we have enabled authentication with the NiFi Registry, the NiFi cluster must also authenticate itself to the registry. For this to happen, both services need to trust each other.

To do this, we have to uncomment the caSecrets configuration block from the nifi_values.yaml. This imports the newly available NiFi Registry certificate into the local truststore of the NiFi nodes. To activate the change, you need to deploy configuration again. If you have copied the whole nifi_values.yaml originally you can use following command to uncomment the lines and redeploy the NiFi nodes:

$> sed -i 's/#[^#]//' nifi_values.yaml && helm upgrade -i -f nifi_values.yaml nifi cetic/nifi

After the cluster nodes have been rebooted, you will need to add a new NiFi registry to the NiFi settings. Navigate to the burger menu at the top right of the NiFi UI and opening the "Controller Settings" menu. Go to the "REGISTER CLIENTS" tab and register a new client using the "+" symbol.
Give it a name and an optional description and save it.
You will then need to edit the newly created entry, go to the "PROPERTIES" tab and set the URL to https://nifi-registry:18080.

This URL https://nifi-registry:18080 is the internal service address within the cluster. Do not use the external URL https://nifi-registry.example.org otherwise the node authentication will fail.

Now only the node authentication is left. For this purpose, each NiFi node is created as a separate user. These can be found by clicking on the burger menu at the top right of the NiFi UI and opening the "Users" menu.

Exactly these users must now be created and authorized in the NiFi Registry. To do this, go to the NiFi Registry UI and click on "LOGIN" in the upper right corner.

Once GitLab has successfully authenticated you, you will be redirected back to your NiFi registry and your username should show up along with a "Settings" icon.

You can click it and create a new "Bucket".

Then switch to the "USERS" Tab and create the NiFi node users with read permissions on "Can manage buckets" and read, write and delete permissions on "Can proxy user requests".

If all steps have been completed successfully, you should now see the "Sample Bucket" in the NiFi UI when you import a "Process Group" from the Registry (drag&drop a Process Group from the header menu and click Import from Registry).

4. Limitations and Troubleshooting

The helm charts cetic/nifi (1.1.4) and dysnix/nifi-registry (1.1.4) are very helpful, but have some limitations.

The latest working NiFi and NiFi Registry docker versions are 1.18.0. The following container versions use Java 11, which brings a new default format (PKCS12 instead of JKS) for the truststore (breaking change).
When deploying the NiFi Registry, a permission error may occur on the auth-conf folder. This is due to a bug in helm chart which omits the setting of permissions on this folder. Either the permissions on this folder have to be set manually once, or the folder has to be added to the initContainers script.
Due to the use of the cert-manager, certificates are issued on the fully qualified internal Kubernetes service name. This is composed as follows:
{{ fullname }}-{{ replicaCount }}.{{ fullname }}-headless.{{ namespace }}.svc.cluster.local.
Since the common name of a certificate may not exceed 64 bytes, this leads to the following name length restriction:
2 * length(fullname) + length(replicaCount) + length(namespace) < 35 characters.
The sensitiveKey and clientSecret secrets cannot be passed as Kubernetes secrets. This means that the configurations should not be pushed into a version control system.
Automatic scaling of an existing NiFi cluster is not possible by simply increasing the replicaCount. Once deployed, you must additionally add the new nodes manually to the configuration of all cluster nodes.

5. Conclusion

This article gave you a tutorial on how to set up a secure Apache NiFi cluster with Apache NiFi Registry integration. It also addresses the limitations and challenges that can arise in this process. If everything worked well, you can now seamlessly dive into modeling data integration workflows and become familiar with Apache NiFi's core functionality. With this knowledge, you're well-equipped to harness the advantages of this powerful platform and effectively handle your data integration tasks.

Top comments (12)

Jannik Rebmann • Mar 24

Update

The restrictions for using Apache NiFi versions `>1.18.0´ (section 4.1) have been fixed:

for cetic/nifi in version 1.2.0 (pull request)
for dysnix/nifi-registry in version 1.1.5 (pull request)

This means that you can now also use the latest Apache NiFi versions.

Anmol bansal • Dec 14 '23

Hi Jannik Rebmann,

I am trying this configuration but i am facing some issue .
Using oidc nifi and nifi-registry redirect-uri is coming as below:

Nifi : https://:443/nifi-api/access/oidc/callback
Nifi-registry: http://:80/nifi-registry-api/access/oidc/callback

is there something i am missing. why nifi-registry oidc redirect uri is coming on http. but in logs it is running on https(18443).

Please help me out here.

kamniphat01 • Mar 8

Hi @anmoln4

I had face this issue before you need add header x-proxyscheme: https and x-proxyport:443 in request-transformer for nifi to redirect https header instead of http

Name:         request-transformer
Namespace:    nifi-test
Labels:       <none>
Annotations:  kubernetes.io/ingress.class: xxxxx
API Version:  configuration.konghq.com/v1
Config:
  Add:
    Headers:
      X-ProxyScheme:https
      X-ProxyPort:443

Hope its help you.

Jannik Rebmann • Dec 14 '23

Hi @anmoln4

I think I need more information about your OIDC configuration.

The Callback URL must be set with your OIDC provider. This is the URL that sends back the OIDC authentication response to your NIFI service.

So maybe you have set http://:80/nifi-registry-api/access/oidc/callback as Callback URL on your OIDC server?

kamniphat01 • Mar 7

Hi @jrebmann ,

I am following your configuration to enabled CertManager, but i am hitting some issue on unable to locate initial admin. Could you possible to share an example for authorizers.xml ?

Error:
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authorizer': FactoryBean threw exception on object creation; nested exception is org.apache.nifi.authorization.exception.AuthorizerCreationException: org.apache.nifi.authorization.exception.AuthorizerCreationException: Unable to locate initial admin JoseAce@xxxx.com to seed policies

authorizers.xml

   {{- if .Values.auth.oidc.enabled}}
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./auth-conf/users.xml</property>
    </userGroupProvider>

    <userGroupProvider>
        <identifier>aad-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.azure.AzureGraphUserGroupProvider</class>
        <property name="Refresh Delay">1 mins</property>
        <property name="Authority Endpoint">https://login.microsoftonline.com</property>
        <property name="Directory ID">{{.Values.auth.oidc.tenantId}}</property>
        <property name="Application ID">{{.Values.auth.oidc.clientId}}</property>
        <property name="Client Secret">{{.Values.auth.oidc.clientSecret}}</property>
        <property name="Group Filter Prefix">{{.Values.auth.oidc.groupPrefix}}</property>
        <property name="Page Size">100</property>
    </userGroupProvider>

    <userGroupProvider>
        <identifier>composite-configurable-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.CompositeConfigurableUserGroupProvider</class>
        <property name="Configurable User Group Provider">file-user-group-provider</property>
        <property name="User Group Provider 1">aad-user-group-provider</property>
    </userGroupProvider>

    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">composite-configurable-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">{{.Values.auth.oidc.admin}}</property>
        <property name="Legacy Authorized Users File"></property>
        <property name="Node Identity 1"></property>
    </accessPolicyProvider>

    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
    {{- end}}

Jannik Rebmann • Mar 7

Hi @kamniphat01,

thanks for your question.
I have never experienced this error.
Please make sure you also have the mail joseace@xxxx.com set in the security and oidc sections.

security:
  ...
  admin: <registered_email>
  ...
oidc:
  ...
  admin: <registered_email>
  ...

kamniphat01 • Mar 8

hi @jrebmann ,

Thanks for the article on how to setup a secure nifi cluster. Now i was able to successfully deploy nifi cluster with oidc method. Appreciate it

Jannik Rebmann • Mar 15

@kamniphat01 You're welcome! Thank you for reading. I hope you will like Apache NiFi ... it has solved so many problems for me.

Heni Nechi • Jun 5 • Edited

am deploying nifi and nifi-registry on aks and everything is working but the integration with git.
I try almost everything
change persistance from true to false, tried username and password auth.
this code is part of the values.yaml of nifi.

registry:
  ## If true, install the Nifi registry
  enabled: true
  url: ""
  port: 80
  # Default values for nifi-registry.
  # This is a YAML-formatted file.
  # Declare variables to be passed into your templates.

  replicaCount: 1

  image:
    repository: apache/nifi-registry
    pullPolicy: Always
    tag: "0.8.0"

  initContainers:
  git:
    image: alpine/git
    tag: v2.26.2
  # alpine:
  #   image: alpine
  #   tag: "3.6"
  # Additional environment variables to set for the initContainers
  extraEnvs: []
  # extraEnvs:
  #   - name: FOO
  #     value: bar

  service:
    type: LoadBalancer
    httpsport: 18080

  ingress:
    enabled: false
    annotations: {}
      # kubernetes.io/ingress.class: nginx
      # kubernetes.io/tls-acme: "true"
    hosts:
      - host: chart-example.local
        paths: []
    tls: []
    #  - secretName: chart-example-tls
    #    hosts:
    #      - chart-example.local

  ## Persist data to a persistent volume
  persistence:
    enabled: false
    database:
      # storageClass: "-"
      accessMode: ReadWriteOnce
      size: 1Gi
    flowStorage:
      # storageClass: "-"
      accessMode: ReadWriteOnce
      size: 1Gi

  resources: {}
    # We usually recommend not to specify default resources and to leave this as a conscious
    # choice for the user. This also increases chances charts run on environments with little
    # resources, such as Minikube. If you do want to specify resources, uncomment the following
    # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
    # limits:
    #   cpu: 100m
    #   memory: 128Mi
    # requests:
    #   cpu: 100m
    #   memory: 128Mi


  bundleProvider:
    file:
      enabled: true
      # -- the path in the running pod where the git repo will be cloned into
      # either absolute or relative to the container working directory, which is NIFI_REGISTRY_HOME
      # If you elect to use a non-default location, you must also update the property associated.
      storageDirectory: ./extension_bundles

  flowProvider:
    git:
      enabled: true
      # Repository to be cloned at pod startup
      url: 'git@github.com:N****ni/***.git'
      # Sets NIFI_REGISTRY_GIT_REMOTE for update_flow_provider.sh
      remote: 'origin'
      # Sets NIFI_REGISTRY_GIT_USER for update_flow_provider.sh
      user: 
      # Sets NIFI_REGISTRY_GIT_PASSWORD for update_flow_provider.sh
      password:
      # passwordSecret(Name|Key) is the name and key of the k8s secret holding the password (can be used instead of password)
      # passwordSecretName:
      # passwordSecretKey:
      # Global Git configuration See https://git-scm.com/docs/git-config for more details.
      config:
        enabled: false
        data: ""
        # data: |
        #   [credential "https://github.com"]
        #           username = foo
      ssh:
        # To use an SSH public/private keypair as a Kubernetes secret:
        # 1. Generate a SSH key named id_rsa:
        #      ssh-keygen -q -N "" -f ./id_rsa
        # 2. Create a Kubernetes secret:
        #      kubectl -n nifi-registry create secret generic nifi-registry-git-ssh --from-file=./id_rsa
        # 3. Don't check these key files into your Git repository! Once you've created
        #    the Kubernetes secret, Delete the private key:
        #      rm ./id_rsa
        # 4. Add ./id_rsa.pub as a deployment key with write access in your Git repo
        # 5. Set the secret name (e.g., nifi-registry-git-ssh) here:
        secretName: 'nifi-registry-git-ssh'
        # 6. Provide the public key(s) of the SSH server(s) for $HOME/.ssh/known_hosts
        knownHosts: |
         github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
        # 7. Set the GIT_SSH_COMMAND
        gitSshCommand: "ssh -v"
        # 8. specify the config which would go in $HOME/.ssh/config file, for e.g.
        # config: |
        #   Host github.com
        #   ProxyCommand socat STDIO PROXY:<proxyIP>:%h:%p,proxyport=<proxyPort>,proxyauth=<username:password>
        #   User git
        #   Hostname ssh.github.com
        #   Port 443
        #   IdentityFile /etc/fluxd/ssh/identity
        # or, if using an SSH public/private keypair:
        config: |
          StrictHostKeyChecking accept-new
    postgres:
      enabled: false
      driverURL: https://jdbc.postgresql.org/download/
      fileName: postgresql-42.2.6.jar
      driverClass: org.postgresql.Driver
      url: jdbc:postgresql://localhost/nifireg
      username: nifireg
      password: nifireg

Jannik Rebmann • Jun 5 • Edited

Hi @heni_nechi,

first of all, I would recommend that you use at least version 1.18.0 of the Apache NIfi Registry. I had a similar problem with the Git integration. I finally solved the problem by using a ssh key.

registry:
   image:
     tag: 1.18.0
   enabled: true
   fullnameOverride: nifi-reg
   persistence:
     enabled: true
   flowProvider:
     git:
       enabled: true
       url: git@gitlab.com:group/repositry.git
       remote: origin
       user: nifi-registry-provider
       password: notUsed
       ssh:
         secretName: nifi-registry-ssh-secret

The corresponding secret looks like following:

apiVersion: v1
kind: Secret
metadata:
 name: nifi-registry-ssh-secret
data:
 id_rsa: "<sshkeyasbase64>"

I hope this helps you.

Heni Nechi • Jun 5

Hello @jrebmann
Thanks for your quick response I tried using the integration with ssh key before, I'll give it a shot again with the code provided and I'll get back to you with a reply.

Heni Nechi • Jun 5

Hey again @jrebmann
as I already told I have tried using the ssh key before and it didn't work same as now.
I really don't know what am doing worng, the secret is being set right by checking the logs it's always defaulting to FileSystemFlowPersistenceProvider and the providers.xml is not being configured :

<providers>

    <!-- NOTE: The providers in this file must be listed in the order defined in providers.xsd which is the following:
            1) Flow Persistence Provider (Must occur once and only once)
            2) Event Hook Providers (May occur 0 or more times)
            3) Bundle Persistence Provider (Must occur once and only once)
     -->

    <flowPersistenceProvider>
        <class>org.apache.nifi.registry.provider.flow.FileSystemFlowPersistenceProvider</class>
        <property name="Flow Storage Directory">./flow_storage</property>
    </flowPersistenceProvider>

    <!--
    <flowPersistenceProvider>
        <class>org.apache.nifi.registry.provider.flow.git.GitFlowPersistenceProvider</class>
        <property name="Flow Storage Directory">./flow_storage</property>
        <property name="Remote To Push"></property>
        <property name="Remote Access User"></property>
        <property name="Remote Access Password"></property>
        <property name="Remote Clone Repository"></property>
    </flowPersistenceProvider>
    -->

    <!--
    <flowPersistenceProvider>
        <class>org.apache.nifi.registry.provider.flow.DatabaseFlowPersistenceProvider</class>
    </flowPersistenceProvider>
    -->

    <!--
    <eventHookProvider>
        <class>org.apache.nifi.registry.provider.hook.ScriptEventHookProvider</class>
        <property name="Script Path"></property>
        <property name="Working Directory"></property>
        -->
        <!-- Optional Whitelist Event types
        <property name="Whitelisted Event Type 1">CREATE_FLOW</property>
        <property name="Whitelisted Event Type 2">DELETE_FLOW</property>
        -->
    <!--
    </eventHookProvider>
    -->

    <!-- This will log all events to a separate file specified by the EVENT_APPENDER in logback.xml -->
    <!--
    <eventHookProvider>
        <class>org.apache.nifi.registry.provider.hook.LoggingEventHookProvider</class>
    </eventHookProvider>
    -->

    <extensionBundlePersistenceProvider>
        <class>org.apache.nifi.registry.provider.extension.FileSystemBundlePersistenceProvider</class>
        <property name="Extension Bundle Storage Directory">./extension_bundles</property>
    </extensionBundlePersistenceProvider>

    <!-- Example S3 Bundle Persistence Provider
            - Requires nifi-registry-aws-assembly to be added to the classpath via a custom extension dir in nifi-registry.properties
                Example: nifi.registry.extension.dir.aws=./ext/aws/lib
                Where "./ext/aws/lib" contains the extracted contents of nifi-registry-aws-assembly
            - "Region" - The name of the S3 region where the bucket exists
            - "Bucket Name" - The name of an existing bucket to store extension bundles
            - "Key Prefix" - An optional prefix that if specified will be added to the beginning of all S3 keys
            - "Credentials Provider" - Indicates how credentials will be provided, must be a value of DEFAULT_CHAIN or STATIC
                - DEFAULT_CHAIN will consider in order: Java system properties, environment variables, credential profiles (~/.aws/credentials)
                - STATIC requires that "Access Key" and "Secret Access Key" be specified directly in this file
            - "Access Key" - The access key to use when using STATIC credentials provider
            - "Secret Access Key" - The secret access key to use when using STATIC credentials provider
            - "Endpoint URL" - An optional URL that overrides the default AWS S3 endpoint URL.
                 Set this when using an AWS S3 API compatible service hosted at a different URL.
     -->
    <!--
    <extensionBundlePersistenceProvider>
        <class>org.apache.nifi.registry.aws.S3BundlePersistenceProvider</class>
        <property name="Region">us-east-1</property>
        <property name="Bucket Name">my-bundles</property>
        <property name="Key Prefix"></property>
        <property name="Credentials Provider">DEFAULT_CHAIN</property>
        <property name="Access Key"></property>
        <property name="Secret Access Key"></property>
        <property name="Endpoint URL"></property>
    </extensionBundlePersistenceProvider>
    -->

registry:
   image:
     tag: 1.18.0
   enabled: true
   fullnameOverride: nifi-reg
   initContainers:
   git:
    image: alpine/git
    tag: v2.26.2
   alpine:
    image: alpine
    tag: "3.6"
   service:
    type: LoadBalancer
    httpsport: 18080
   persistence:
     enabled: true
   flowProvider:
     git:
       enabled: true
       url: git@github.com:NechiHeni/flow.git
       remote: origin
       user: NechiHeni
       password: 
       ssh:
         secretName: nifi-registry-ssh-secret

View full discussion (12 comments)

DEV Community

Setup a secure Apache NiFi cluster in Kubernetes

Motivation

Prerequisites

1. Preparations

1.1 Enable ingress in minikube

1.2 Integrate `kubectl` for minikube

1.3 Install cert-manager in minikube

1.4 Map NiFi domains to minikube

1.5 Register OpenID connect (OIDC) clients

2. Setup an Apache NiFi cluster

3. Setup an Apache NiFi Registry

4. Configure Apache NiFi

4. Limitations and Troubleshooting

5. Conclusion

Top comments (12)

Update

Read next

Weekly AI Highlights Review: November 5–12

Sharing Secrets Between Kubernetes Clusters Using external-secrets PushSecret

Talend vs. Apache Kafka: Which Data Tool Drives Better Business Insights?

New AttackVector Jailbreaks LLMs by Prompt Manipulation

Motivation

Prerequisites

1. Preparations

1.1 Enable ingress in minikube

1.2 Integrate kubectl for minikube

1.3 Install cert-manager in minikube

1.4 Map NiFi domains to minikube

1.5 Register OpenID connect (OIDC) clients

2. Setup an Apache NiFi cluster

3. Setup an Apache NiFi Registry

4. Configure Apache NiFi

4. Limitations and Troubleshooting

5. Conclusion

Update

Read next

Weekly AI Highlights Review: November 5–12

Sharing Secrets Between Kubernetes Clusters Using external-secrets PushSecret

Talend vs. Apache Kafka: Which Data Tool Drives Better Business Insights?

New AttackVector Jailbreaks LLMs by Prompt Manipulation

1.2 Integrate `kubectl` for minikube