Skip to main content
NetApp Solutions

Data encryption in transit

Contributors kevin-hoke
PDFs

Data in transit can be encrypted at the NAS protocol layer, and the Google Cloud network itself is encrypted, as described in the following sections.

Google Cloud network

Google Cloud encrypts traffic on the network level as described in Encryption in transit in the Google documentation. As mentioned in the section “Google Cloud NetApp Volumes architecture,” Google Cloud NetApp Volumes is delivered out of a NetApp-controlled PSA producer project.

In case of NetApp Volumes-SW, the producer tenant runs Google VMs to provide the service. Traffic between user VMs and Google Cloud NetApp Volumes VMs is encrypted automatically by Google.

Although the data path for NetApp Volumes-Performance isn’t fully encrypted on the network layer, NetApp and Google use a combination of IEEE 802.1AE encryption (MACSec), encapsulation (data encryption), and physically restricted networks to protect data in transit between the Google Cloud NetApp Volumes NetApp Volumes-Performance service type and Google Cloud.

NAS protocols

NFS and SMB NAS protocols provide optional transport encryption at the protocol layer.

SMB encryption

SMB encryption provides end-to-end encryption of SMB data and protects data from eavesdropping occurrences on untrusted networks. You can enable encryption for both the client/server data connection (only available to SMB3.x capable clients) and the server/domain controller authentication.

When SMB encryption is enabled, clients that do not support encryption cannot access the share.

Google Cloud NetApp Volumes supports RC4-HMAC, AES-128-CTS-HMAC-SHA1, and AES-256-CTS-HMAC-SHA1 security ciphers for SMB encryption. SMB negotiates to the highest supported encryption type by the server.

NFSv4.1 Kerberos

For NFSv4.1, NetApp Volumes-Performance offers Kerberos authentication as described in RFC7530. You can enable Kerberos on a per-volume basis.

The current strongest available encryption type for Kerberos is AES-256-CTS-HMAC-SHA1. Google Cloud NetApp Volumes supports AES-256-CTS-HMAC-SHA1, AES-128-CTS-HMAC-SHA1, DES3, and DES for NFS. It also supports ARCFOUR-HMAC (RC4) for CIFS/SMB traffic, but not for NFS.

Kerberos provides three different security levels for NFS mounts that offer choices for how strong the Kerberos security should be.

As per RedHat’s Common Mount Options documentation:

sec=krb5 uses Kerberos V5 instead of local UNIX UIDs and GIDs to authenticate users.
sec=krb5i uses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.
sec=krb5p uses Kerberos V5 for user authentication, integrity checking, and encrypts NFS traffic to prevent traffic sniffing. This is the most secure setting, but it also involves the most performance overhead.

As a general rule, the more the Kerberos security level has to do, the worse the performance is, as the client and server spend time encrypting and decrypting NFS operations for each packet sent. Many clients and NFS servers provide support for AES-NI offloading to the CPUs for a better overall experience, but the performance impact of Kerberos 5p (full end-to-end encryption) is significantly greater than the impact of Kerberos 5 (user authentication).

The following table shows differences in what each level does for security and performance.

Security level Security Performance

NFSv3—sys

  • Least secure; plain text with numeric user IDs/group IDs

  • Able to view UID, GID, client IP addresses, export paths, file names, permissions in packet captures

  • Best for most cases

NFSv4.x—sys

  • More secure than NFSv3 (client IDs, name string/domain string matching) but still plain text

  • Able to view UID, GID, client IP addresses, name strings, domain IDs, export paths, file names, permissions in packet captures

  • Good for sequential workloads (such as VMs, databases, large files)

  • Bad with high file count/high metadata (30-50% worse)

NFS—krb5

  • Kerberos encryption for credentials in every NFS packet—wraps UID/GID of users/groups in RPC calls in GSS wrapper

  • User requesting access to mount needs a valid Kerberos ticket (either through username/password or manual key tab exchange); ticket expires after a specified time period and user must reauthenticate for access

  • No encryption for NFS operations or ancillary protocols like mount/portmapper/nlm (can see export paths, IP addresses, file handles, permissions, file names, atime/mtime in packet captures)

  • Best in most cases for Kerberos; worse than AUTH_SYS

NFS—krb5i

  • Kerberos encryption for credentials in every NFS packet—wraps UID/GID of users/groups in RPC calls in GSS wrapper

  • User requesting access to mount needs a valid Kerberos ticket (either via username/password or manual key tab exchange); ticket expires after a specified time period and user must reauthenticate for access

  • No encryption for NFS operations or ancillary protocols like mount/portmapper/nlm (can see export paths, IP addresses, file handles, permissions, file names, atime/mtime in packet captures)

  • Kerberos GSS checksum is added to every packet to ensure nothing intercepts the packets. If checksums match, conversation is allowed.

  • Better than krb5p because the NFS payload is not encrypted; only added overhead compared to krb5 is the integrity checksum. Performance of krb5i won’t be much worse than krb5 but will see some degradation.

NFS – krb5p

  • Kerberos encryption for credentials in every NFS packet—wraps UID/GID of users/groups in RPC calls in GSS wrapper

  • User requesting access to mount needs a valid Kerberos ticket (either via username/password or manual keytab exchange); ticket expires after specified time period and user must reauthenticate for access

  • All of the NFS packet payloads are encrypted with the GSS wrapper (cannot see file handles, permissions, file names, atime/mtime in packet captures).

  • Includes integrity check.

  • NFS operation type is visible (FSINFO, ACCESS, GETATTR, and so on).

  • Ancillary protocols (mount, portmap, nlm, and so on) are not encrypted - (can see export paths, IP addresses)

  • Worst performance of the security levels; krb5p has to encrypt/decrypt more.

  • Better performance than krb5p with NFSv4.x for high file count workloads.

In Google Cloud NetApp Volumes, a configured Active Directory server is used as Kerberos server and LDAP server (to lookup user identities from an RFC2307 compatible schema). No other Kerberos or LDAP servers are supported. NetApp highly recommends that you use LDAP for identity management in Google Cloud NetApp Volumes. For information on how NFS Kerberos is shown in packet captures, see the section link:ncvs-gc-cloud-volumes-service-architecture.html#Packet sniffing/trace considerations[“Packet sniffing/trace considerations.”]