How do export-policies work in ONTAP?

Export policies

• Export policies determine access to volumes for NFS (and optionally CIFS) in ONTAP.
  • Each volume is associated with one export-policy.
  • Each policy can have multiple rules.
  • Each policy must have at least one valid rule in order to grant access.
• An export-policy without export-policy rules will prevent access for any volumes associated with it.
• Newly created SVMs have no export-policy rules for its default policy, and therefore do not allow data access until a rule has been created.
• Each volume in an SVM is associated with one of the vserver's export policies. By default, it is associated with the vserver's default export-policy.
• Access to a volume is determined by the export policy rules in the export policy the volume is associated with.
• Access to a volume requires not only access permission through the export policy rules of that volume, but all parent volumes in the junction-path as well. (this is why the recommended SVM/vserver root volume policy rule allows at least read access to all clients on the network with a client match of 0.0.0.0/0).

If a client is only allowed access through the policy associated with a volume, but the policy of parent volumes in the junction-path do not at least allow read access for this client, the client will still not be able to access the relevant volume.

• To see what policy each volume has associated, run volume show -fields policy.

Export-policy rules

• Every rule includes
  • SVM
  • export-policy name
  • client IP range or addresses to which it applies
  • an index number
  • a read-only rule
  • a read-write rule. 

The required rule flags are as follows: 

• Client IP range - The client IP range is either a specific address or a subnet, like 10.0.3.212 or 192.168.5.0/24, a hostname, or a netgroup, like @netgroup. If you want an export policy to apply to all possible IP4 addresses, set the clientmatch to 0.0.0.0/0. 
• Index numbers - Export policy rules have an index number, and are evaluated one by one based upon that number from low to high, where the first rule that applies to a client IP is the one that will be used. For example, if an export-policy has an export policy rule at index 1 that allows only read-only access to 192.168.0.0/16, any additional export-policy rules at index 2 or later that regard an IP address or IP address range inside the 192.168.0.0/16 range (like a read-write rule for subnet 192.168.5.0/24) will not have any effect. Rule indexes can be changed with the export-policy rule setindex command.
• RO-rule - The ro-rule specifies for which security style(s) you want to allow read-only access for the clients relevant, specified in the client match. You can specify multiple security styles by using a comma. The RO rule supersedes the RW rule, so if RW is required for a certain protocol, it has to also be included in the RO rule.
  Options:
  • any - includes ntlm, sys and krb5
  • none - none is a complex option not commonly used, and is not to be confused with never. (It is similar to none in 7-mode export rules). See the paragraph on none below. 
  • never - specifies that no client gets read-only access
  • krb5 - refers to either CIFS or NFS kerberos authentication 
  • ntlm - refers to CIFS client using the ntlm authentication mechanism
  • sys - only refers to sys style security, specific to NFS clients 
• RW-rule - The rw-rule specifies for which security style(s) you want to allow write access for the clients relevant, specified in the client match. You can specify multiple security styles by using a comma. The RO rule supersedes the RW rule, so if RW is required for a certain protocol, it has to also be included in the RO rule.
  Options:
  • any  - includes ntlm, sys and krb5
  • none - none is a complex option not commonly used, and is not to be confused with never. (It is similar to none in 7-mode export rules). See the paragraph on none below. 
  • never - specifies that no client gets read-write access
  • krb5 - refers either CIFS or NFS kerberos authentication 
  • ntlm - refers to CIFS client using the ntlm authentication mechanism
  • sys - only refers to sys style security, specific to NFS clients

The optional rule flags are as follows:

• protocol - The protocol option allows you to create a separate rule for CIFS and NFS (and different versions of NFS). With this option, you can have one rule for CIFS access for a subnet, and a different one for NFS. For example, you can allow krb5 write access over CIFS, while having krb5 access denied over NFS, by setting up a separate rule for the same subnet for the different protocols that use krb5. This also allows you to force NFSv4 access if you don't want to allow NFSv3 or vice versa.
• anon - The anon option sets the uid for the anon user.
  If you want root to stay root when entering an NFS export in Cluster-Mode, set the superuser to sys (see below). If you want to set the anon user to a different uid than 65534 when either RW or RO are set to security style none use this anon option. If you want to block root access completely (still allowing mounts) you can set this to 65535.
• Superuser - The superuser option allows you to specify for which security style root users are allowed to stay root and not get squashed to anon. You can specify multiple security styles by using a comma. This option will take precedence over the anon option, so any client this applies to will have its root user stay root, even if anon is set to a different value than 0.
  Options:
  • any - includes ntlm, sys and krb5
  • none - This is the default in cDOT 8.2 and later. It causes root to get squashed to the anon value (default 65534). .
  • never - This is the default in cDOT 8.0 and 8.1, which causes root to get squashed to the anon value (default 65534). This option was removed in 8.2, as it acts the same as the none option.
  • krb5 - refers either CIFS or NFS kerberos authentication. CIFS superusers are deprecated in Cluster-Mode, but might still be used in certain scenarios.
  • ntlm - refers to CIFS client using the ntlm authentication mechanism. CIFS superusers are deprecated in Cluster-Mode, but might still be used in certain scenarios.
  • sys - only refers to sys style security, specific to NFS clients. This is the correct setting to disable root squashing.

The superuser option can be used to prevent the root from becoming anonymous for certain clients, while still allowing anon settings to apply to other security features. Besides above example of RO/RW security of none, it can be used to distinguish between krb5 and sys for anon=0: if you want root to be squashed to an anonymous uid (like the default 65534) for NFS sys, but stay root for kerberized NFS in one rule, you can set anon to 65534, and superuser to krb5. By doing this, only if kerberos auth is used, will root actually stay root when entering an export.

This is a very uncommon case, and in most scenarios where root squashing is not desired for a specific client match, one would just set superuser to sys or sys,krb5.

The 'none' option for RW and RO
The 'none' option specifies that for all security styles that are not already specified in this rule flag (as mentioned, more than one style can be given by using a comma), users who are accessing will be given the ID of the anonymous user. By default, this ID is 65534; however, this globally mapped id in case of none can be changed with the anon option. This anon uid will be given a default gid based on the default gid for the uid the user is mapped to (this determined by the name services specified in the vserver ns-switch setting, i.e. with local unix-user and unix-group tables or through nis or ldap name services). When clients communicate over nfs with rw and ro set to none, no uid or gid is actually shared by the client, which is fine as the cluster will map all users to that anon uid. This corresponds with the sec=none option in Data ONTAP 7-Mode.

For creating export rules on Clustered Data ONTAP 8.3 refer vserver export-policy rule create

A basic example

If for the default policy you want read and write access over sys and krb5 to all possible clients, and you don't want root squashed for either protocol, you can create a rule with below command.

Cluster1::> vserver export-policy rule create -policyname default -clientmatch 0.0.0.0/0 -rorule sys,krb5 -rwrule sys,krb5 -superuser sys,krb5