Restrict access to your Amazon FSx for NetApp ONTAP volumes using export policies

Users who support multi-tenant environments need shared storage platforms that can securely isolate data between clients. For example, imagine a pharmaceutical company with several divisions, each working on different product lines. Storage administrators need to prevent one division from viewing or accessing the files and data from the projects of the others. They use export policies to control client access to files, directories, and volumes, which only allow an end-user to access shares for their division.

Amazon FSx for ONTAP is a fully managed service that provides highly reliable, scalable, high-performing, and feature-rich file storage built on NetApp’s popular ONTAP file system. With FSx for ONTAP, each file system hosts one or more Storage Virtual Machines (SVMs) and each SVM functions as an endpoint where clients connect and then access their data. Client data is stored in logical containers, called volumes, within each SVM. These volumes are affected by various policies, such as a snapshot policies, tiering policies, and export policies.

In this post we explore using export policies, and associated export policy rules, to control which clients have access to shares and exports. By default, export policies apply to the NFS protocol, and they allow or restrict access to NFS clients. Optionally, export policies can be enabled for SMB (or CIFS) clients, and in this post, we demonstrate how this can be applied.

Solution overview

When an FSx for ONTAP file system is provisioned, one or more SVMs are created. Each SVM has an associated “root” volume that stores SVM metadata (for example NFS exports). FSx for ONTAP automatically creates a default export policy called default for each SVM’s root volume, and this is the policy that is applied to each new data volume as it’s created. The default policy allows access from any client (0.0.0.0/0) to any volume. The default export policy can be used for the volumes contained in the SVM, or multiple unique export policies can be created as needed. The default export policy can be modified and renamed, but it can’t be deleted. An export policy can be applied to multiple volumes, but each volume has only one associated export policy. Export policies contain one or more export rules, which define allowed clients, protocols, and access types.

Export rules are the functional elements of an export policy. Export rules match client access requests to a volume against specific parameters that determine how to handle the request. An export policy must contain at least one export rule to allow access to clients. If an export policy contains more than one rule, then the rules are processed in the order in which they appear in the export policy. The rule order is dictated by the rule index number. If a rule matches a client, then the permissions of that rule are used, and no further rules are processed. If no rules match, then the client is denied access. Clients must match all the parameters of a rule for the request to be granted.

Export rules can assess client access by using the following criteria:

• The file access protocol used by the client sending the request, for example, NFSv4 or SMB (optional – must be enabled).
• A client identifier, for example, host name, IP address, or subnet (the maximum size for the -clientmatch field is 4096 characters).
• The security type used by the client to authenticate, for example, Kerberos v5, NTLM, or AUTH_SYS.

Note that export policy configuration checking can be enabled as a background job that records rules violations in an error rule list. The vserver export-policy config-checker commands invoke the checker and display results, which you can use to verify your configuration and delete erroneous rules from the policy. The commands only validate export configuration for host names, netgroups, and anonymous users.

Required flags in an export rule must include the following:

• SVM
• export-policy name
• a clientmatch rule (hostname, subnet, or netgroup)
• a rule index number
• a read-only rule
• a read-write rule

Optional flags in an export rule can include the following:

• protocol (NFS version or SMB)
• superuser security style (default is none / root squash)
• anonymous ID (default 65534)

Example: A client with IP 10.0.21.32 tries to connect to an FSx for ONTAP volume over NFS version 4.2 using auth_sys authentication. The volume is configured with an export policy that has two rules.

Rule 1:

• Protocol = NFSv3
• Clientmatch = 10.1.16.0/24
• Rorule = any
• Rwrule = krb5, ntlm

The client does not match all the criteria of Rule 1, thus access is not granted, but more rules are processed.

Rule 2:

• Protocol = NFS
• Clientmatch = 10.0.21.0/24
• Rorule = any
• Rwrule = krb5, ntlm

The client matches the subnet range, protocol, and the read-only authentication method in Rule 2, but not the read-write method, thus access is granted as read-only to the volume.

Figure 1: A flow chart for the client access request workflow

For the complete export rule reference pages, refer to the vserver export-policy rule create command line interface (CLI) guide for NetApp ONTAP.

Note that this post assumes that you have created a file system and an SVM, and you have volumes that are ready to be exported or shared. To understand those prerequisite steps, observe the FSx for ONTAP user guide. Export policies and rules can be created and managed through the ONTAP CLI, the ONTAP API, or through NetApp BlueXP Systems Manager. This post covers the ONTAP CLI method of implementation.

Scenario

In this example scenario a user has deployed an FSx for ONTAP file system to support several research divisions within their organization. Each division runs jobs from a fleet of instances that are specific to the project to which they are assigned. The projects may have one or more clients per project, but each client runs only jobs for their respective project and doesn’t perform work on other projects. However, some divisions do occasionally need to read the data from other group’s completed projects. The storage administrator has provisioned volumes for each research team and now needs to restrict access based on team membership, as shown in Figure 2:

Figure 2: chart describing teams and necessary access levels

Figure: 3 shows a high level architecture for the solution in this post.

Figure 3: high level architecture for the solution

Walkthrough

The following steps walk you through this solution.

Step 1: Enable export policies for SMB client access

Export policies for SMB access is disabled by default. To control SMB access using export policies, it must first be enabled, as shown in the following code and figure. From the CLI of the FSx for ONTAP file system:

• Set the privilege level to advanced:

set -privilege advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

• Enable export policies for SMB clients:

vserver cifs options modify -vserver <SVM_name> -is-exportpolicy-enabled true

• Return to the admin privilege level:

set -privilege admin

Figure 4: Screenshot of the CLI commands enabling export policies for SMB clients

Step 2: Create the export policies

From the CLI of the FSx for ONTAP instance, as shown in the following code and Figure 5:

Template: vserver export-policy create -policyname <policy_name> -vserver <SVM_name>

	vserver export-policy create -policyname research_team_one -vserver researchsvm01

	vserver export-policy create -policyname research_team_two -vserver researchsvm01

	vserver export-policy create -policyname research_team_three -vserver researchsvm01

Figure 5: Screenshot of the CLI command for creating an export policy

Step 3: Create the export policy rules

Creating the export policy rules, as shown in the following code and Figure 6:

Template: vserver export-policy rule create -vserver <SVM_name> -policyname <policy_name> -clientmatch <subnet_or_hostname> -rorule <krb5,ntlm,any,none,sys> -rwrule <krb5,ntlm,any,never,sys> -protocol <nfs,cifs> -ruleindex <integer>

Volume One:
	vserver export-policy rule create -vserver researchsvm01 -policyname research_team_one -clientmatch 10.0.2.0/24 -rorule any -rwrule any -protocol nfs,cifs -ruleindex 1

Volume two:
	vserver export-policy rule create -vserver researchsvm01 -policyname research_team_two -clientmatch 10.0.3.0/24 -rorule any -rwrule any -protocol nfs -ruleindex 1
	vserver export-policy rule create -vserver researchsvm01 -policyname research_team_two -clientmatch 10.0.4.128/25 -rorule any -rwrule never -protocol cifs -ruleindex 2

Volume three: 
	vserver export-policy rule create -vserver researchsvm01 -policyname research_team_three -clientmatch 10.0.3.0/24 -rorule any -rwrule never -protocol nfs -ruleindex 1
	vserver export-policy rule create -vserver researchsvm01 -policyname research_team_three -clientmatch 10.0.4.0/25 -rorule any -rwrule any –protocol nfs3 -ruleindex 2
	vserver export-policy rule create -vserver researchsvm01 -policyname research_team_three -clientmatch 10.0.4.128/25 -rorule any -rwrule any –protocol cifs -ruleindex 3

Figure 6: Screenshot of the CLI command for creating an export policy rule

Step 4: Apply the export policies to the volumes

Before applying the newly created policies, first check the status of the existing volumes, as shown in the following code and Figure: 7.

volume show -vserver researchsvm01 -fields policy

Figure 7: Screenshot of the CLI showing output of the “volume show policy” command

Apply the polices to the volumes, as shown in the following code and Figure 8:

Template: volume modify -vserver <SVM_name> -volume <volume_name> -policy <export_policy_name>

	volume modify -vserver researchsvm01 -volume vol1 -policy research_team_one
	volume modify -vserver researchsvm01 -volume vol2 -policy research_team_two
	volume modify -vserver researchsvm01 -volume vol3 -policy research_team_three

Figure 8: Screenshot of the CLI commands modifying a volume export policy

Step 5: Verify the policies are working

For this post, we demonstrate the permissions as they apply to clients belonging to team three. According to the preceding client table, team three should have no access to team one’s volumes, SMB read-only access to team two’s volumes, and full read/write access to their volume over SMB and NFSv3.

In testing team three’s access to team one’s volume over SMB, the client reports that it can’t access the shared volume, as shown in Figure 9:

Figure 9: Screenshot showing team three is blocked from SMB access to team one’s volume

Similarly, a team three client reports that access is denied by the server when trying to access team one’s shared volume using the NFS protocol, as shown in the Figure 10:

Figure 10: Screenshot showing team three is blocked from NFS access of team one’s volume

Access is also denied when trying to access team two’s shared volume over the NFS protocol from the same team three client, as shown in Figure 11:

Figure 11: Screenshot showing a team three client is denied access to mount team two’s volume using NFS

However, when accessing team two’s shared volume from a team three SMB Windows client, read-only access is granted. As expected, the attempt to write to the file fails, as shown in Figure 12:

Figure 12: Screenshot showing team three client is allowed to read, but blocked from writing data, to team two’s volume when using the SMB protocol

Access to their own shared volume allows both read/write access for an SBM client in the expected subnet, as shown in Figure 13:

Figure 13: Screenshot showing team three is allowed access over SBM for access to their volume

Finally, read/write access to their own shared folder is allowed for an NFSv3 client, as shown in Figure 14:

Figure 14: Screenshot showing team three has NFSv3 read/write access to their shared volume

For a bonus test, the same client is prevented from mounting the same volume over the NFSv4 protocol, as shown in Figure 15:

Figure 15: Screenshot showing team three is denied access to their own volume when mounting over NFSv4

Cleaning up

There are costs associated with running EC2 instances and Amazon FSx for NetApp ONTAP file systems. Remember to delete and terminate these resources if they are no longer required. To delete a file system, follow the instructions on the Amazon FSx for NetApp ONTAP user guide. To terminate your Amazon EC2 instances, see “Terminate Your Instance” in the Amazon EC2 User Guide.

Conclusion

In this post we demonstrated how you can make sure that the correct access controls are in place for your volumes across your organization by showing how to configure export policies and rules that restrict access to various Amazon FSx for NetApp ONTAP volumes based on client parameters. This results in a more secure file storage environment, where only authorized users have their access granted, while unauthorized user requests are denied. We also walked you through a demonstration showing how rules function in-action in different situations.

Thank you for reading this post. To learn more about FSx for ONTAP, observe the FSx for ONTAP user guide. If you have any comments or questions, leave them in the comments section.