Apache NiFi 1.0.0 - Kerberos Authentication
Apache NiFi supports several authentication mechanisms and provides a pluggable authentication model, allowing anyone to implement a custom identity provider. By default, NiFi always supports two-way SSL as an authentication mechanism, but also provides the ability to use LDAP or Kerberos. This post will demonstrate how to use Kerberos for authentication.
Setting up a KDC
In order to do anything with Kerberos, the first thing we need to do is setup a KDC. For this post we are going to use the docker-kdc project which makes it really easy to run a KDC on any environment.
I’m working on OSX and had previously installed docker-machine. The docker-kdc project was originally created to work with boot2docker, so to work around that we can do the following:
Create a boot2docker machine:
docker-machine create --driver virtualbox boot2docker eval "$(docker-machine env boot2docker)"
Create /usr/local/bin/boot2docker with the contents provided here
We also need to install a library called jq, which I did using homebrew:
brew install jq
After that we can clone the docker-kdc git repo and cd into the directory:
git clone https://github.com/tillt/docker-kdc.git cd docker-kdc
At the root of this directory create a file named kdc.json which will be the config file used when setting up the KDC:
This tells docker-kdc to create two principals, the first represents the end-user that will authenticate to NiFi, and the second is the principal that NiFi will use to talk to the KDC.
We can now build and start the KDC:
./kdc build ./kdc start
We can test the KDC by running ./kdc test and should output similar to the following:
Checking boot2docker active... ok Trying to connect to KDC... at 192.168.99.101:48088... ok
As part of starting the KDC, a krb5.conf and krb5.keytab were generated in the docker-kdc directory.
The krb5.conf is the configuration file that clients would use to talk to the KDC running in the docker container, and krb5.keytab contains the keytabs for the principals that were specified in kdc.json.
In order to setup the current shell to leverage the krb5.conf generated by docker-kdc, and not the one in /etc, run the following command:
We should now be able to perform a kinit against the KDC using one of the principals that we specified:
Performing a klist should show something like the following:
One last bit of setup is that we will have to access NiFi using nifi.apache.org as the hostname in order to line up with the domain in our KDC.
Edit /etc/hosts and map nifi.apache.org to localhost:
127.0.0.1 localhost nifi.apache.org
In order to perform any type of authentication, NiFi has to be configured to use https. I’ve previously covered how to create certificates and truststores using the NiFi Toolkit, so I’m going to assume readers can do that at this point.
The nifi.properties related to https would look something like the following:
nifi.remote.input.secure=true nifi.web.https.host=localhost nifi.web.https.port=9445 nifi.security.keystore=./conf/keystore.jks nifi.security.keystoreType=jks nifi.security.keystorePasswd=<your password> nifi.security.keyPasswd=<your password> nifi.security.truststore=./conf/truststore.jks nifi.security.truststoreType=jks nifi.security.truststorePasswd=<your password>
We also need to set some additional properties related to Kerberos:
nifi.security.user.login.identity.provider=kerberos-provider nifi.kerberos.krb5.file=/path/to/docker-kdc/krb5.conf nifi.kerberos.spnego.principal=HTTP/[email protected] nifi.kerberos.spnego.keytab.location=/path/to/docker-kdc/krb5.keytab nifi.kerberos.spnego.authentication.expiration=12 hours
The login identity provider is the identifier of a provider defined in login-identity-providers.xml. We need to edit login-identity-providers.xml and uncomment the kerberos-provider:
<provider> <identifier>kerberos-provider</identifier> <class>org.apache.nifi.kerberos.KerberosProvider</class> <property name="Default Realm">NIFI.APACHE.ORG</property> <property name="Authentication Expiration">12 hours</property> </provider>
The last thing we need to do is configure the Intial Admin Identity in authorizers.xml:
<property name="Initial Admin Identity">[email protected]</property>
If you remember from previous posts, we usually put the DN from a certificate here, but since we are going to authenticate with Kerberos, the admin needs to be the principal for our end user.
At this point we can start NiFi:
There are two ways we can authenticate to NiFi using Kerberos:
- Kerberos Login - NiFi presents a login screen and authenticates the user against the KDC
- SPNEGO - A ticket that was established outside of NiFi is forwarded to NiFi through the browser
If we navigate to NiFi in our browser at https://nifi.apache.org:9445/nifi, assuming we didn’t already configure our browser for SPNEGO, then we should get prompted with a login screen:
NOTE: If you have a client certificate in your browser that corresponds to this NiFi instance, you may get prompted to use that certificate, but we want to decline in this case so that we end up at the login page.
At this login screen we can enter the principal name and password (in this example bbende and bbende) and we should get authenticated and see the NiFi UI:
Using SPNEGO requires some extra configuration in your browser.
Using Firefox requires going to the about:config page and setting the following properties:
NOTE: The trusted URIs are the host and port being used to access NiFi in the browser, which in this case is https://nifi.apache.org:9445. This works because of the mapping we setup earlier to map nifi.apache.org to localhost.
If you followed the steps earlier, you probably already have a ticket, but you can check by issuing klist. If you don’t see a ticket for your user principal then you need to perform a kinit:
You should then be able to go to the NiFi UI in your browser without requiring a login.
Using Chrome you can perform similar steps to configure it. From the terminal where you performed the kinit, run the following commands:
defaults write com.google.Chrome AuthServerWhitelist "nifi.apache.org" defaults write com.google.Chrome AuthNegotiateDelegateWhitelist "nifi.apache.org"
You can verify the policies were set by opening Chrome and entering chrome://policy in the address bar.
blog comments powered by Disqus