In case you were living under a rock somewhere, VMWare released vSphere 6.0 in March. I covered some of my thoughts from a NFS perspective in vSphere 6.0 – NFS Thoughts.
In that blog, I covered some of the new features, including support for Kerberized NFS on vSphere 6.0. However, in my experience of setting up Kerberos for NFS clients, I learned that doing it can be a colossal pain in the ass. Luckily, vSphere 6.0 actually makes the process pretty easy.
TR-4073: Secure Unified Authentication will eventually contain information on how to do it, but I wanted to get the information out now and strike while the iron is hot!
What is Kerberos?
I cover some scenarios regarding securing your NFS environment in “Feeling insecure about NFS?” One of those I mention is Kerberos, but I never really go into detail about what Kerberos actually is.
Kerberos is a ticket-based authentication process that eliminates the need to send passwords over the wire in text format. Instead, passwords are stored on a centralized server (known as a Key Distribution Center, or KDC) that issues tickets to grant tickets for access. This is done through varying levels of encryption, which is controlled via the client, server and keytabs. Right now, the best you can do is AES, which is the NIST standard. Clustered Data ONTAP 8.3 supports both AES-128 and AES-256, by the way. 🙂
However, vSphere 6.0 supports only DES, so…
Again, TR-4073: Secure Unified Authentication covers this all in more detail than you’d probably want…
Kerberize… like a rockstar!
In one of my Insight sessions, I break down the Kerberos authentication process as a real-world scenario, such as buying a ticket to see your favorite band.
- A person joins a fan club for first access to concert tickets
- Ticket Granting Ticket (TGT) issued from Key Distribution Center (KDC)
- A person buys the concert ticket to see their favorite band
- TGT used to request Service Ticket (ST) from the KDC
- They pick the ticket up at the box office
- They use the ticket to get into the concert arena
- The ticket specifies which seat they are allowed to sit in
- Authorization; backstage pass specifies what special permissions they have
One of the questions you may be asking, or have heard asked is, “why the heck do I want to Kerberize my NFS datastore mount? Doesn’t my export policy rule secure it enough?”
Well, how easy is it to change an IP address of an ESXi server? How easy is it to create a user? That’s really all you need to mount NFSv3. However, Kerberos requires a user name and password to get a ticket, interaction with a KDC, ticket exchange, etc.
So, it’s much more secure.
Awesome… how do I do it?
Glad you asked!
After you’ve set up your KDC and preferred NFS server to do Kerberos, you’d need to set the client up. In this case, the client is vSphere 6.0.
Step 1: Configure DNS
Kerberos needs DNS to work properly. This is tied to how service principal names (SPNs) are queried on the KDC. So, you need the following:
- Forward and reverse lookup records on the DNS server for the ESXi server
- Proper DNS configuration on the ESXi server
Step 2: Configure NTP
Kerberos is very sensitive to time skew. There is a default of 5 minutes allowed between client/server/KDC. If the skew is outside of that, the Kerberos request will fail. This is for your security. 🙂
Step 3: Join ESXi to the Active Directory Domain
This essentially saves you the effort of messing with manual configuration of creating keytabs, SPNs, etc. Save yourself time and headaches.
Step 4: Specify a user principal name (UPN)
This user will be used by ESXi to kinit and grab a ticket granting ticket (TGT). Again, it’s entirely possible to do this manually and likely possible to leverage keytab authentication. But, again, save yourself the headache.
Step 5: Create the NFS datastore for use with NFSv4.1 and Kerberos authentication
You *could* Kerberized NFSv3. But why? All that gets encrypted is the NFS stuff. NLM, NSM, portmap, mount, etc don’t get Kerberized. NFSv4.1 encapsulates all things related to the protocol, so encrypting NFSv4.1 encrypts it all.
Enter the server/datastore information:
Be sure you don’t forget to enable Kerberos:
After you’re done, test it out!