Security considerations

This page provides an overview of Google Cloud NetApp Volumes security considerations.

Security considerations for networking

Google Cloud NetApp Volumes provides a secure architectural framework with the following isolated security layers:

  • Project-level security: the administrative security layer that administrators use to manage NetApp Volumes resources like storage pools or volumes using the Google Cloud console, Google Cloud SDK, or APIs. IAM roles and permissions guard this layer. For more information about project-level security, see Set up IAM permissions.

  • Network-level security: the network layer used to access data volumes with network-attached storage (NAS) protocols (Server Message Block (SMB) and Network File System (NFS)).

    You can access data within volumes using NAS protocols through a Virtual Private Cloud network. All data access to NetApp Volumes is possible only through your VPC, unless you explicitly use a third-party solution to replace VPC peering routing to your VPCs.

    Within the VPC, you can limit access further with firewalls and through the setup of protocol-specific access control mechanisms.

Firewall rules for volumes access

Firewall rules protect Google Cloud VPC. To enable access from clients to NetApp Volumes, you need to allow specific network traffic.

Firewall rules for NFS volumes access

NFS uses various ports to communicate between the client and a server. To ensure proper communication and successful volume mounts, you must enable ports on your firewalls.

NetApp Volumes acts as an NFS server and exposes the network ports required for NFS. Make sure your NFS clients have permission to talk to the following NetApp Volumes ports:

  • 111 TCP/UDP portmapper

  • 635 TCP/UDP mountd

  • 2049 TCP/UDP nfsd

  • 4045 TCP/UDP nlockmgr (for NFSv3 only)

  • 4046 TCP/UDP status (for NFSv3 only)

The IP addresses for NetApp Volumes are automatically assigned from the CIDR range you assigned to the service during network peering. For more information, see Choose a CIDR.

Advisory lock use with NFSv3

If you use advisory locks with NFSv3, you need to run the rpc.statd daemon on your client to support Network Lock Manager, which is a facility that works in cooperation with the NFS to provide a System V style of advisory file and record locking over the network. Your NFS client must open an ingress port for rpc.statd to receive Network Lock Manager callbacks. In most Linux distributions, rpc.statd starts when you mount the first NFS share. It uses a random port which you can identify using the rpcinfo -p command. To make rpc.statd more firewall friendly, configure it to use a static port.

To set static ports for rpc.statd, refer to the following resources:

If you don't use NFSv3 advisory locks, or Network Lock Manager, we recommend that you mount your NFSv3 shares with the nolock mount option.

NFSv4.1 implements the lock function within the NFSv4.1 protocol itself, which runs over the client-initiated TCP connection to the NFSv4.1 server on port 2049. The client doesn't need to open firewall ports for ingress traffic.

Firewall rules for SMB volumes access

SMB uses various ports to communicate between the client and a server. To ensure proper communication, you must enable ports on your firewalls.

NetApp Volumes acts as an SMB server and exposes the network ports SMB requires. Make sure your SMB client is allowed to talk to the following NetApp Volumes ports:

  • 445 TCP SMB2/3

  • 135 TCP msrpc and 40001 TCP SMB CA: Used only for SMB 3.x continuously available shares. These ports aren't required for non-continuously available shares.

The service exposes, but doesn't use, port 139/TCP.

The IP addresses for NetApp Volumes are automatically assigned from the CIDR range you assigned to the service during network peering. For more information, see Choose a CIDR.

Your SMB clients don't need to expose ingress ports for SMB to work.

Firewall rules for Active Directory access

Open the following ports on all your Active Directory domain controllers to traffic originating from the CIDR range for NetApp Volumes:

  • ICMPV4

  • DNS 53 TCP

  • DNS 53 UDP

  • LDAP 389 TCP

  • LDAP 389 UDP

  • LDAP (GC) 3268 TCP

  • SAM/LSA 445 TCP

  • SAM/LSA 445 UDP

  • Secure LDAP 636 TCP

  • Secure LDAP 3269 TCP

  • W32Time 123 UDP

  • AD Web Svc 9389 TCP

  • Kerberos 464 TCP

  • Kerberos 464 UDP

  • Kerberos 88 TCP

  • Kerberos 88 UDP

Attach firewall tag to Active Directory servers

Use the following instructions to attach the firewall tag to your Active Directory servers.

  1. Attach the firewall tag to your Active Directory servers:

    gcloud compute firewall-rules create netappvolumes-to-activedirectory \
  --allow=icmp,TCP:53,UDP:53,TCP:88,UDP:88,UDP:123,TCP:389,UDP:389,TCP:445,UDP:445,TCP:464,UDP:464,TCP:636,TCP:3268,TCP:3269,TCP:9389 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-activedirectory \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

    Replace the following information:

    • NETAPP_VOLUMES_CIDR: The NetApp Volumes CIDR

    • VPC_NAME: The name of the VPC

  2. Attach the following tag to your domain controllers:

    allow-netappvolumes-to-activedirectory

Volume access controls for NFS protocols

NetApp Volumes guards access by NFS protocols with a single export policy with up to 20 export rules. Export rules are comma-separated lists of IPv4 addresses and IPv4 CIDRs that specify which clients have permission to mount volumes. NetApp Volumes evaluates export rules in sequential order and stops after the first match. We recommend ordering export rules from most specific to most generic for best results.

Use the following tabs to review policies based on NFS versions:

NFS without Kerberos

All NFS versions without Kerberos use the AUTH_SYS security flavor. In this mode, you must tightly manage the export rules to allow only clients you trust and which can ensure user ID and group ID integrity.

As a security measure, NFS servers automatically map NFS calls with UID=0 (root) to UID=65535 (anonymous), which has limited permissions on the file system. During volume creation, you can enable the root access option to control this behavior. If you enable root access, user ID 0 stays 0. As a best practice, create a dedicated export rule which enables root access for your well-known administrator hosts and disable root access for all other clients.

NFSv4.1 with Kerberos

NFSv4.1 with Kerberos use export policies and additional authentication using Kerberos to access volumes. You can configure export rules to apply for the following:

  • Kerberos only (krb5)

  • Kerberos signing (krb5i)

  • Kerberos privacy (krb5p)

Volume access controls for SMB protocol

SMB uses share-level permissions to guard volume access and require authentication against Active Directory.

Volumes are created with Everyone and Full Control share-level permissions. You can modify share-level permissions using the Computer Management Microsoft Management Console.

File access control

The following sections provide details on NetApp Volumes file-level access control.

Volume security style

NetApp Volumes offers two security styles for volumes, UNIX and NTFS, to accommodate the different permission sets of Linux and Windows platforms.

  • UNIX: volumes configured with the UNIX security style use UNIX mode bits and NFSv4 ACLs to control file access.

  • NTFS: volumes configured with NTFS security style use NTFS ACLs to control file access.

The security style of the volume depends on the protocol choice for the volume:

Protocol type Volume security style
NFSv3 UNIX
NFSv4.1 UNIX
Both (NFSv3 and NFSv4.1) UNIX
SMB NTFS
Dual (SMB and NFSv3) UNIX or NTFS
Dual (SMB and NFSv4.1) UNIX or NTFS

For dual protocols, you can only choose security style during volume creation.

NFS file-level access control for UNIX-style volumes

After a client mounts a volume successfully, NetApp Volumes checks access permissions to files and directories using the standard UNIX permission model called mode bits. You can set and modify permissions using chmod.

NFSv4.1 volumes can also use NFSv4 access control lists (ACLs). If a file or directory has both mode bits and an NFSv4 ACL, the ACL is used for permission checking. The same applies to volumes which use both NFSv3 and NFSv4.1 protocol types. You can set and modify NFSv4 ACLs using nfs4_getfacl and nfs4_setfacl.

When you create a new UNIX-style volume, the root:root has ownership of root inode and 0770 permissions. Due to this ownership and permission setting, a non-root user gets a permission denied error while accessing the volume after mounting. To enable access to the volume for non-root users, a root user must change the ownership of the root inode using chown and modify the file permissions using chmod.

SMB file access control for NTFS-style volumes

For NTFS-style volumes, we recommend that you use an NTFS permission model. Every file and directory has an NTFS ACL which you can modify using File Explorer, the icacls command line tool, or PowerShell. In the NTFS permission model, new files and folders inherit permissions from their parent folder.

Multi-protocol user mapping

For dual-protocol volumes, clients can use NFS and SMB to access the same data. A volume is configured by setting the security style of the volume to either have UNIX or NTFS permissions.

When you create a dual-protocol SMB and NFS volume, we strongly recommend that Active Directory contains a default user. The default user is used when an NFS client sends an NFS call with a user ID that isn't available in Active Directory. NetApp Volumes then tries to look up a user called pcuser, which acts as a default UNIX user. If that user isn't found, access is denied to the NFS call.

We recommend that you create a default user in Active Directory with the following attributes:

  • uid = pcuser

  • uidnumber = 65534

  • cn = pcuser

  • gidNumber = 65534

  • objectClass = user

Depending on the protocol used by the client (NFS or SMB) and the security style of the volume (UNIX or NTFS), NetApp Volumes can directly check access permissions of the user or requires mapping the user to the other platform's identity first.

Access protocol Security style Identity used by protocol Required mapping
NFSv3 UNIX User ID and group ID N/A
NFSv3 NTFS User ID and group ID User ID to username to security identifier
SMB UNIX Security identifier Security identifier to username to user ID
SMB NTFS Security Identifier N/A

When mapping is required, NetApp Volumes relies on data stored in Active Directory LDAP. For more information, see Active Directory use cases.

Multi-protocol user mapping scenario: SMB access to a UNIX volume

Scientist Charlie E. (charliee) wants to access a NetApp Volumes volume using SMB from a Windows client. Because the volume contains machine generated results provided by a Linux compute cluster, the volume is configured to store UNIX permissions.

The Windows client sends an SMB call to the volume. The SMB call contains the user identity as a security identifier. The security identifier isn't comparable against the user ID and group ID file permissions and requires mapping.

To complete the required mapping, NetApp Volumes takes the following steps:

  1. NetApp Volumes asks Active Directory to resolve the security identifier to a username, for example, S-1-5-21-2761044393-2226150802-3019316526-1224 to charliee.

  2. NetApp Volumes asks Active Directory to return the user ID and group ID for charliee.

  3. NetApp Volumes checks access against the ownership user ID and group ID of the file using the returned user ID and group ID.

Multi-protocol user mapping scenario: NFS access to an NTFS volume

Engineer Amal L. needs to access some data on a volume from a Linux client using NFS. Because the volume is mainly used to store Windows data, it is configured with the NTFS security style.

The Linux client sends an NFS call to NetApp Volumes. The NFS call contains user ID and group ID identifiers which can't be matched to a security identifier without mapping.

To complete the required mapping, NetApp Volumes asks Active Directory for the username of the user ID and to return the security identifier for the username, and then checks access against the owner security identifier of the accessed file using the returned security identifier.

Encryption in Transit

NFS

For NFS volumes, use NFSv4.1 with Kerberos encryption enabled for maximum security.

SMB

For SMB volumes, enable AES encryption in your Active Directory policy and SMB encryption on your volume for maximum security.

Volume replication

NetApp Volumes can replicate volumes across Google Cloud regions to provide data protection. Since the traffic resides in the Google Cloud, the transfer process is secure as it uses Google's network infrastructure, which has limited access to prevent unauthorized interception. Additionally, the replication traffic is encrypted using FIPS 140-2 compliant TLS 1.2 standards.

Integrated backup

An integrated backup creates backups of NetApp Volumes within the service. The backup traffic stays within Google's secure network infrastructure using FIPS 140-2 compliant TLS 1.2 standard encryption. Additionally, the backup vaults store these backups using Google-managed key encryption for added security.

What's next

Secure NetApp Volumes with a service perimeter.