In today's dynamic landscape, many clients, ranging from influential banks and healthcare giants to government entities, rely on cutting-edge applications that demand unwavering security fortifications and strict adherence to regulatory frameworks. Their paramount mission? To safeguard sensitive data with an ironclad grip, ensuring that access is meticulously restricted and employing robust encryption protocols for data at rest and in motion, effectively shielding data from prying eyes and potential threats. Enter Google Cloud NetApp Volumes (NetApp Volumes).
NetApp Volumes ensures encryption of data at rest, leaving no room for compromise. Harnessing the power of cutting-edge technology, these volumes offer a choice between Google-managed encryption keys and customer-managed encryption keys (CMEK), fortifying your data fortress with an extra layer of protection.
But what about data in transit? Google Cloud does encrypt data in transit, but some customers prefer to use their own encryption. Although SMB effortlessly enables encryption in transit with its built-in capabilities, NFS takes a different approach and instead uses Kerberos, a strong authentication and encryption protocol.
As the guardian of your data, Kerberos orchestrates user authentication to NFS volumes in Google Cloud NetApp Volumes and allows only authenticated users access to the volumes. Also, after authentication is complete, NFSv4.1 can use the Kerberos exchanged session key to encrypt the data in transit between the virtual machines and NetApp Volumes, ensuring that no spying eyes will be able to read your data as shown below.
This article describes one way to set up and validate Kerberos with Google Cloud NetApp Volumes in 10 steps. It shows how to mount a virtual machine running Red Hat Enterprise Linux 8.10 for in-transit NFSv4.1 encryption.
Set up and validate Kerberos with Google Cloud NetApp Volumes
Note: Based on your environment, your setup steps may be different.
This procedure requires an Active Directory already installed on a virtual machine in Google Cloud and reachable from the client virtual machine and NetApp Volumes.
To watch a video of this procedure, go to Kerberos with Google Cloud NetApp Volumes.
Step 1: Set up Active Directory policy on NetApp Volumes
Operating Google Cloud NetApp Volumes with Kerberos requires connectivity from NetApp Volumes to your Active Directory. It also requires a log in to the Kerberos realm with rights to create a computer organizational unit. This connection and login are accomplished by creating an Active Directory policy. You must have an Active Directory policy for each region using Kerberos, and you may have more than one Active Directory policy for each region.
The following screenshot shows an example of setting up an Active Directory policy for a region using the Google Cloud NetApp Volumes UI. Of course, you can also do this via the API.
Select Active Directory Policies from the left menu. Click and then fill in the values. Although not shown in the screenshot, you will also be asked for your NetBIOS name prefix, KDC hostname, and IP, which is the hostname and IP of a valid AD domain controller. Also enter a username and password for an account with rights to create a computer organizational unit. Check the box marked “Enable AES encryption for Active Directory authentication.” When you have finished scrolling down, click Create.
Note: “Allow local NFS users with LDAP” enables local client users to access NFS volumes and disables extended user groups from accessing NFS volumes for NFS client users not in AD. If you don’t have an LDAP server, leave this option unselected. If you have an LDAP server and want to also use local UNIX users (such as root), select this option. We left it unselected.
The Active Directory Policy will come up immediately and should be in the Ready state..
For information about how to test Active Directory connectivity, go to Google Cloud NetApp Volumes: Test Active Directory connectivity.
Step 2: Create a storage pool connecting the AD policy
Create a storage pool where your Kerberos-enabled volumes will reside. Make sure that the Active Directory policy created in Step 1 is assigned and that LDAP is turned on. You can also use CMEK if you have set up a CMEK policy for that region. The following screenshot shows an example of creating a storage pool with an AD policy and LDAP configuration. We used the Flex service level for this pool.
Step 3: Create a volume with Kerberos
Create an NFSv4.1 volume in a storage pool that uses an Active Directory policy and has LDAP turned on for NFS. Select the Enable Kerberos checkbox.
The Kerberos mode is selected during the export policy configuration. NetApp Volumes supports three Kerberos modes: krb5, krb5i, and krb5p. Kerberos 5 and 5i require authentication only, but 5p requires encryption in flight. You will only be able to mount the volume to a VM with the same Kerberos mode that is enabled on the volume. For example, if you enable krb5 and krb5p, the VMs that mount with mode krb5 will only require authentication, while those that mount with mode krb5p will also encrypt data in flight. To require encryption in flight, be sure to enable only the krb5p mode, as shown in the following example.
In this case, all VMs coming from the IP subnet 192.0.2.0/24 are required to mount with Kerberos 5p and to have root access turned off. A root user on the virtual machine does not have root access on the volume.
Step 4: Install packages on the VM
Ensure your Linux VMs hostname does not exceed 15 characters due to the NetBIOS limitation. Install the necessary packages on your Linux VM.
$ sudo yum -y install realmd sssd oddjob oddjob-mkhomedir adcli samba-common krb5-workstation nfs-utils bind-utils rpc.gssd
Be sure NTP is installed and synchronized with the AD server.
Step 5: Set up the DNS in the Active Directory server
In your Active Directory server, make sure that the VM IP address and domain name are added to the DNS. If you are in a test environment, you can manually add the VM name to the DNS Manager on the AD server. Right-click the domain, select New Host (A or AAAA), and add the server information to the DNS database. Select “Create an associated pointer (PTR) record.”
At this point, both the VM and the storage pool should be in the DNS server. To check, access the DNS -> <AD name> -> <domain>. Both the storage pool and the virtual machine should be listed with their IP addresses. The storage pool registered itself with the Active Directory policy. An example storage pool is shown below.
Step 6: Test the DNS
On the VM, change the /etc/resolv.conf file. Add your domain to the domain, search your domain, and add your DNS IP address (which is also your AD server). An example resolv.conf file is shown below.
$ cat /etc/resolv.conf
# Generated by NetworkManager
domain cvsdemo.internal
search cvsdemo.internal us-east5-c.c.cvs-pm-host-1p.internal c.cvs-pm-host-1p.internal google.internal
nameserver 192.0.2.3
#nameserver 169.254.169.254
If the VM is rebooted after DNS configuration, the /etc/resolv.conf file may be overwritten. In that case, re-enter the information and restart NetworkManager.
Test DNS lookups. In the following example, the name of the VM is kerberos-vm1. Make sure that your VM name resolves to an FQDN.
$ nslookup kerberos-vm1
Server: 192.0.2.3
Address: 192.0.2.3#53
Name: kerberos-vm1.cvsdemo.internal
Address: 192.0.2.13
Step 7: Configure Kerberos on the client virtual machine
Edit the /etc/krb5.conf file, as shown in the following example. Replace the realm, FQDN for active directory, and so on with your Information.
$ cat /etc/krb5.conf
# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = CVSDEMO.INTERNAL
udp_preference_limit = 0
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
CVSDEMO.INTERNAL = {
kdc = ok-activedirectory.cvsdemo.internal
admin_server = ok-activedirectory.cvsdemo.internal
}
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
.cvsdemo.internal = CVSDEMO.INTERNAL
cvsdemo.internal = CVSDEMO.INTERNAL
Discover the Kerberos realm from the client:
$ realm discover cvsdemo.internal
cvsdemo.internal
type: kerberos
realm-name: CVSDEMO.INTERNAL
domain-name: cvsdemo.internal
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
Become root (or use sudo) and join the VM to the realm. The user used to join (in this case janedoe) must have administrator privileges on the Active Directory.
# realm join --user=janedoe cvsdemo.internal
Password for janedoe@CVSDEMO.INTERNAL:
# realm list
cvsdemo.internal
type: kerberos
realm-name: CVSDEMO.INTERNAL
domain-name: cvsdemo.internal
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
login-formats: %U@cvsdemo.internal
login-policy: allow-realm-logins
Double-check the sssd.conf file to be sure that it has the correct realm and other information.
# cat /etc/sssd/sssd.conf
[sssd]
domains = cvsdemo.internal
config_file_version = 2
services = nss, pam
[domain/cvsdemo.internal]
ad_domain = cvsdemo.internal
krb5_realm = CVSDEMO.INTERNAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
Step 8: Mount the volume
Make sure that rpc-gssd is running. This is necessary to mount the volume. The rpc-gssd service will not come up until Kerberos is running, so it may not be running. If it is not running, be sure to restart it.
# systemctl restart rpc-gssd
# systemctl status rpc-gssd
● rpc-gssd.service - RPC security service for NFS client and server
Loaded: loaded (/usr/lib/systemd/system/rpc-gssd.service; static; vendor preset: disabled)
Active: active (running) since Wed 2024-11-13 16:56:15 UTC; 3s ago
Process: 76428 ExecStart=/usr/sbin/rpc.gssd (code=exited, status=0/SUCCESS)
Main PID: 76429 (rpc.gssd)
Tasks: 2 (limit: 23183)
Memory: 1.2M
CGroup: /system.slice/rpc-gssd.service
└─76429 /usr/sbin/rpc.gssd
Nov 13 16:56:15 kerberos-vm1 systemd[1]: Starting RPC security service for NFS client and server...
Nov 13 16:56:15 kerberos-vm1 systemd[1]: Started RPC security service for NFS client and server.
As root, make a mount point and mount the volume as root. Be sure to use Kerberos for the security option. In the following example, we used Kerberos 5p to match the volume creation in Step 3.
# mkdir /kerberos
# mount -o sec=krb5p smb-us-e5-47c2.cvsdemo.internal:/kerberos-volume /kerberos
Create a file in the volume to use for validation later.
# cd /kerberos
# ls
# ls -la
total 4
drwxrwxrwx. 2 nobody nobody 4096 Nov 13 16:28 .
dr-xr-xr-x. 18 root root 240 Nov 13 15:34 ..
# touch test.txt
# ls
test.txt
Step 9: Set up a user account with Kerberos
Next we create a non-root user and give that user access to the volume.
If you don’t already have LDAP on the Linux virtual machine with users created, create a new user on the Linux VM. Assign a user ID and group ID. Give the user a password.
$ sudo groupadd group11 -g 10000
$ sudo useradd sherlock -u 20003 -g 10000
$ sudo su
# passwd sherlock
Changing password for user sherlock.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Create the same username and group on the Active Directory. To map SPN to the UNIX user, go to the AD under Users and Computers -> Users. Right-click Users, select New, and then select User. Name the user with the same name as the Linux user. Next, double-click the new user and select Attribute Editor. Change the UID to the name of the user (in this case sherlock) and the UIDNumber to the number that is on the client (in this case 20003).
Do the same thing for the group (gidNumber needs to match the group on the Linux VM) for that same group.
Step 10: Validate Kerberos
Back on the VM, try to access the mountpoint as the user created in step 8. It should fail.
Log the new user into the Kerberos realm using kinit and then perform a klist to show the Ticket Granting Ticket (krbtgt).
[root@kerberos-vm1 /]# su - sherlock
Last login: Thu Nov 14 21:28:09 UTC 2024 on pts/0
[sherlock@kerberos-vm1 ~]$ cd /secret
-bash: cd: /secret: Permission denied
[sherlock@kerberos-vm1 ~]$ kinit
Password for sherlock@CVSDEMO.INTERNAL:
[sherlock@kerberos-vm1 ~]$ klist
Ticket cache: KCM:20003
Default principal: sherlock@CVSDEMO.INTERNAL
Valid starting Expires Service principal
11/14/2024 13:44:05 11/14/2024 23:44:05 krbtgt/CVSDEMO.INTERNAL@CVSDEMO.INTERNAL
renew until 11/21/2024 13:44:00
Access the new volume mounted in step 8 and then perform another klist to show the new ticket for the nfs volume. (The command klist -e shows the encryption.)
[sherlock@kerberos-vm1 ~]$ cd /kerberos
[sherlock@kerberos-vm1 kerberos]$ ls
test.txt
[sherlock@kerberos-vm1 kerberos]$ klist -e
Ticket cache: KCM:20003
Default principal: sherlock@CVSDEMO.INTERNAL
Valid starting Expires Service principal
11/14/2024 13:44:05 11/14/2024 23:44:05 krbtgt/CVSDEMO.INTERNAL@CVSDEMO.INTERNAL
renew until 11/21/2024 13:44:00, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
11/14/2024 13:44:20 11/14/2024 23:44:05 nfs/smb-us-e5-ddd0.cvsdemo.internal@CVSDEMO.INTERNAL
renew until 11/21/2024 13:44:00, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Now what?
As is often the case with critical security measures, trade-offs come into play. The use of Kerberos necessitates the on-the-fly encryption of data, which introduces a performance degradation when compared to unencrypted traffic. Therefore, it is crucial to ensure that your application is able to operate seamlessly within the realm of Kerberos.
If you need high security in the cloud, including authorization for accessing data and encrypting your data in transit with your session keys, try out Google Cloud NetApp Volumes with Kerberos. It will help you to breathe easy, knowing that all of your data is safe from prying eyes.
Learn more about Google Cloud NetApp Volumes! Contact a specialist for more information.