Access control with NFS export policies
NFS export policies are a set of rules that manage client access to NFS volumes by specifying which clients can connect. They are used to grant access by defining rules based on client IP addresses or CIDR blocks, specify read-only or read-write permissions, and control superuser access. These policies act as a critical security layer that works alongside file-level permissions.
How NFS export policies work
In Google Cloud NetApp Volumes, each volume with NFS access has one export policy with up to 20 export policy rules. When a client attempts to connect, its request is processed against the rules. The order of rules is important. After the first match, evaluation is stopped. If no rule matches, access is denied.
Matching is always based on the IP address of the NFS request sent by the NFS client to NetApp Volumes, which acts as an NFS server.
How export rules are used to manage access
Each export rule has a few parameters.
Mandatory parameters:
- allowed-clients specifies a list of client IPs or CIDR blocks which have access to the volume.
- access-type specifies the kind of access. It can be either READ-WRITE or READ-ONLY.
- nfsv3 and nfsv4 need to be set to true or false to control which protocol the rule applies to.
Optional parameters:
- has-root-access controls if NFS requests of a client's root user (UID=0) stay root (UID=0), or are remapped to nobody (UID=65535) for file access. For security reasons, you want to map every client's root user to nobody and only allow root access to a very limited set of tightly controlled administrative clients. Enabling has-root-access is also known as no_root_squash on Linux NFS servers. Disabling corresponds to root_squash. The default value is true.
- On top of NFS client IP address based access control, users can enable Kerberos for user identity based file access control. With Kerberos, users identity is established based on tickets which the user generates by authenticating against a central authentication server (key distribution center KDC). Kerberos offers strong user identification, but comes with additional complexities of having to manage the Kerberos infrastructure and user identities.
When using Kerberos, read or write access to the volume can be enabled using plain Kerberos5 (KRB), Kerberos integrity (KRB5i) and Kerberos encryption (KRB5p) with the following parameters:
- kerberos-5-read
- kerberos-5-write
- kerberos-5i-read
- kerberos-5i-write
- kerberos-5p-read
- kerberos-5p-write
Please note that the spelling of each parameter differs for API use (e.g. “allowedClients”), gcloud usage (e.g. “allowed-clients”), Terraform (e.g. “allowed_clients”) or Google Cloud Console (e.g. “Allowed clients”).
Export rules define which NFS client can access the volume. They don’t control what a client is allowed to do inside the volume once it has access to the volume. What files a user can read or write is determined by the UID/GID of the user and the access permissions of an individual file or directory.
Introducing anonymous volume access
For some use cases, administrators also want to disable file access control and grant everyone read and write permissions to all files. A typical use case is running an SFTP server in front of an NFS volume where users can exchange files. To eliminate access permission problems a common usage pattern is to translate all incoming UIDs into one. Every file written will be stored with that central UID, instead of the UID of the user who writes the data. This is known as all_squash in Linux NFS servers.
To accommodate anonymous access, NetApp Volumes adds a new export rule parameter called squash-mode to control UID mapping. It can have the following values:
- no-root-squash corresponds to has-root-access=true. The root user (UID=0) stays root when accessing the volume.
- root-squash corresponds to has-root-access=false. The root user (UID=0) gets mapped to nobody (UID=65535) when accessing the volume.
- all-squash maps all incoming users to one UID number, which the administrator can specify using the anon-uid parameter. When using all-squash, access-type needs to be read-write.
As a volume administrator you can create export rules using either has-root-access or squash-mode. Don’t use both in the same rule, but you can mix them in different rules within a volumes export policy.
How to use squash-mode?
The NetApp Volumes API supports the squashMode and anonUid parameters as part of an export policy rule.
Gcloud added the parameters squash-mode and anon-uid to the export-policy parameter block of gcloud netapp volumes create/update. Here’s an example which sets an export policy on an existing NFS volume:
gcloud netapp volumes update oknfs \
--location=northamerica-northeast1 \
--storage-pool=mypool \
--export-policy=access-type=READ_WRITE,nfsv3=true,allowed-clients=10.0.1.0/24,has-root-access=true \
--export-policy=access-type=READ_WRITE,nfsv3=true,allowed-clients=10.0.2.0/24,squash-mode=ALL_SQUASH,anon-uid=2000
To use squash_mode and anon_uid with Terraform, use Google provider version 7.17.0 or later. Here’s an example of an export policy which uses a classic rule style using has_root_access and a new rule using squash_mode:
resource "google_netapp_volume" "nfsv3-volume" {
location = var.region
name = "squash-nfsv3-volume"
capacity_gib = 100
share_name = "squash-nfsv3-volume"
storage_pool = google_netapp_storage_pool.my-tf-pool.name
protocols = ["NFSV3"]
unix_permissions = "0777"
export_policy {
rules {
access_type = "READ_WRITE"
allowed_clients = "10.0.1.0/24"
has_root_access = true
nfsv3 = true
}
rules {
access_type = "READ_WRITE"
allowed_clients = "10.0.2.0/24"
squash_mode = "ALL_SQUASH"
anon_uid = 2000
nfsv3 = true
}
}
}
What rule style to use?
Should you use the classic rule style with has-root-access or the new style with squash-mode? Until squash-mode is supported by Cloud Console, continuing to use has-root-access is the safe choice which will cause the least amount of confusion.
If you prefer to use squash-mode instead because that’s what you are used to from Linux already and don’t care about manageability from Cloud Console, feel free to use squash-mode.
If you need to use the new all-squash feature, use squash_mode = ALL_SQUASH and anon_uid = <uid>.
