== What I see as good options today for encrypted NFS A comment on [[my entry on NFS with Kerberos versus normal NFS NFSVsNFSWithKerberos]] mentioned that one advantage of NFS with Kerberos is that it can encrypt all of the NFS traffic between your servers (whether they be NFS clients or NFS servers). My view is that there are better ways to achieve this in today's world, ones that I trust more for this purpose. The first option is to use [[IPsec https://en.wikipedia.org/wiki/IPsec]] for at least the NFS traffic between NFS servers and NFS clients. IPsec has the advantage that IPsec security policies will generally let you encrypt all NFS traffic and only the NFS traffic, so you don't have to spend CPU cycles encrypting other traffic (if any). You'd most likely want to set up an [[IKE https://en.wikipedia.org/wiki/Internet_Key_Exchange]] environment to establish IPsec keys between relevant machines and to authenticate them. The second option is to use some kind of VPN system, with the NFS servers running VPN endpoints and the NFS clients authenticating to them to create encrypted connections. To force all NFS traffic to be encrypted, you would give the NFS servers and NFS clients IP addresses that can only be reached over a VPN connection, then do your NFS mounts (and NFS mount permissions) using those IP addresses (or names associated only with them). Like IPsec, a well done version of this would have the side effect of authenticating all of the machines involved. You'd distribute the necessary VPN configurations, keys, and identification information through whatever existing configuration management system you use for your servers. If I was doing this, I would use [[WireGuard https://www.wireguard.com/]] if possible. (Since you want all of the NFS servers to be VPN endpoints, you're naturally interested in [[mesh-capable VPN solutions ../sysadmin/VPNMeshAppeal]].) Given that encryption is encryption, I would expect good implementations of any of these options to have performance comparable to NFS with Kerberos. WireGuard is reportedly capable of significant bandwidth under the right circumstances, so hopefully other options can perform decently as well. You wouldn't get as much NFS bandwidth (with as little CPU overhead) as you would without encryption, so if the best bandwidth possible is your priority you need to build a physically secure network and run NFS unencrypted over it. Even if NFS with Kerberos had no other effects, I would rather use one of these other options to get encrypted NFS, for two reasons. The largest reason is that I have far more trust in the cryptographic quality and security of something like WireGuard than I do in NFS with Kerberos, because the former is much more of interest to people and thus much more scrutinized. The lesser reason is that using Kerberos necessarily means your Kerberos server (or servers) are now a critical part of your NFS infrastructure. (Of course, you might already have Kerberos as a critical part of your environment for other reasons.) PS: Done well, both IPsec and VPNs will authenticate all of the machines involved to each other. It's not sufficient for an imposter to grab an IP address of a NFS server or client and start talking; they'd also need the machine's key material as well. In some environments this is important. Of course at this point you get into provisioning issues and how secure the provisioning process is.