NetApp Export Policies Tutorial
I cover Export Policies for NAS protocols in this NetApp training video tutorial. Export Policies and rules enable you to restrict access to volumes and qtrees.
GET YOUR FREE eBOOK
Step by step instructions on how to build a complete NetApp lab, all on your laptop for free.
Sign up to get the eBook and occasional newsletter updates. Your email address will never be shared.
NetApp Export Policies
NetApp Export policies and rules enable the administrator to restrict access to volumes and qtrees (none/ro/rw/superuser) based on the client’s IP address, protocol (NFS/CIFS) and authentication type (None/Sys/Kerberos/NTLM).
You can also set standard UNIX or NTFS permissions.
A NetApp export policy with export rules must exist on the SVM for NFS clients to access data.
By default, export policies do not apply to CIFS shares.
Export policies can be specified at the volume or qtree level. Qtrees inherit from the parent volume by default.
Each volume has only one export policy.
The same export policy can be used on multiple volumes or qtrees to give them the same client access. Different export policies can be used on different volumes or qtrees to give them different client access.
NetApp Export Policy Rules
NetApp export policies are containers for export policy rules.
If a client does not match any rule in the export policy, then access is denied. If an export policy is empty, then all accesses are implicitly denied.
When you create your SVM with FlexVol volumes, the storage system automatically creates a default export policy called default for the root volume of the SVM, with no rules.
You must create one or more rules for the default export policy before clients can access data on the SVM. You can alternatively create custom export policies.
The rule order is dictated by the rule index number. If a rule matches a client, the permissions of that rule are used and no further rules are processed.
You configure export rules to determine client access permissions using the following criteria:
- File access protocol
- Client identifier
- Security type
All three criteria must be specified in each rule.
NetApp Export Rules – File Access Protocol
You can configure the following options for the File Access Protocol (CIFS and NFS can be specified in the same rule):
- All NFS versions
NetApp Export Rules – Client Identifiers
You can configure the following Client Identifiers:
- Domain name preceded by dot (.example.com)
- IPv4 or IPv6 address
- IPv4 subnet with slash notation or subnet mask
(10.10.10.0/24 or 10.10.10.0 255.255.255.0)
Use 0.0.0.0/0 to match all IPv4 addresses
- IPv6 subnet with slash notation
- Netgroup preceded by @ (@netgroup1)
NetApp Export Rules – Security Type
Clients which match the File Access Protocol and Client Identifier are granted ro, rw and/or superuser access to the system based on their security type. ro, rw and superuser rights are granted separately.
Multiple comma-separated security types can be specified in the same export rule. Any and None are always used on their own.
- krb5: A matching client can access the data if it is authenticated by Kerberos 5
- krb5i: A matching client can access the data if it is authenticated by Kerberos 5i.
- ntlm: A matching client can access the data if it is authenticated by CIFS NTLM.
- sys: A matching client can access the data if it is authenticated by NFS AUTH_SYS (local accounts)
- any: A matching client can access the data regardless of security type.
- none: If listed alone, clients with any security type are granted access as anonymous. If listed with other security types, clients with a specified security type are granted access and clients with any other security type are granted access as anonymous. The anon user ID must be set.
- never: A matching client cannot access the data regardless of security type.
There are three possible access levels in export rules:
- Superuser (for clients presenting with user ID 0)
Access level by security type is evaluated in that order.
Clients with Unlisted Security Types
The security type is how the client authenticated, for example Kerberos v5, NTLM, or AUTH_SYS.
When a client presents itself with a security type that is not listed in an export rule or is not authenticated at all (security type AUTH_NONE), you have the choice of either denying access to the client or mapping it to the anonymous user ID instead.
By default the client will be denied access.
You can use the option none to grant access as anon. The -anon parameter determines what user ID is assigned to those clients. The anon user ID will need permission to the files and directories to use them.
Anon User ID
- 0-65533: The client access request is mapped to the anonymous user ID and gets access depending on the permissions configured for that user.
- 65534: The client access request is mapped to the user pcuser and gets access depending on the permissions configured for this user. This is the default. (Linux clients typically map 65534 to the user nobody).
- 65535: The access request from any client is denied when mapped to this ID and the client presents itself with security type AUTH_NONE
- The access request from clients with user ID 0 is denied when mapped to this ID and the client presents itself with any other security type.
Superuser Access Requests
Clients may attempt to access the system as the root User ID 0. This is dangerous from a security point of view.
By default, clients presenting with user ID 0 are mapped to the anonymous user. However, you can specify the – superuser parameter in export rules to change this.
The following are valid options for the -superuser parameter:
- none: This is the default setting if you do not specify the -superuser parameter in the export rule.
When a client presents as User ID 0 and the –superuser parameter is not set, the default is none and the user is squashed to the anon User ID
When a client presents as User ID 0 and the –superuser parameter is set:
- If the -superuser parameter and the client’s security type match, then the client gets superuser access with user ID 0
- If the -superuser parameter and the client’s security type do not match, then the client gets access as the anon User ID. This is regardless of whether the read-only or read-write parameter specifies the option none.
Checking Client Access
To allow exports to be listed from clients:
vserver nfs modify -vserver vs1 -showmount enabled
To view exports from a client:
showmount –e LIF_IP_Address
To check client access rights:
vserver export-policy check-access -vserver vs1 -client-ip 126.96.36.199 –volume flex_vol -authentication-method sys -protocol nfs3 -access-type read-write -qtree qt1
Securing NFS access using export policies from NetApp.