NFS securing
Export rules are the functional elements of an export policy. Export rules match client access requests for a volume against specific parameters you configure to determine how to handle the client access requests. An export policy must contain at least one export rule to allow access to clients. If an export policy contains more than one rule, the rules are processed in the order in which they appear in the export policy.
Access control is central to maintaining a secure posture. Therefore, ONTAP uses the export policy feature to limit NFS volume access to clients that match specific parameters. Export policies contain one or more export rules that process each client access request. An export policy is associated with each volume to configure client access to the volume. The result of this process determines whether the client is granted or denied (with a permission-denied message) access to the volume. This process also determines what level of access is provided to the volume.
An export policy with export rules must exist on an SVM for clients to access data. An SVM can contain multiple 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. If no rules match, the client is denied access.
Export rules determine client access permissions by applying the following criteria:
-
The file access protocol used by the client sending the request (for example, NFSv4 or SMB)
-
A client identifier (for example, host name or IP address)
-
The security type used by the client to authenticate (for example, Kerberos v5, NTLM, or AUTH_SYS)
If a rule specifies multiple criteria, and the client does not match one or more of them, the rule does not apply.
An example export policy contains an export rule with the following parameters:
-
-protocol nfs
-
-clientmatch 10.1.16.0/255.255.255.0
-
-rorule any
-
-rwrule any
The security type determines which level of access a client receives. The three access levels are read-only, read-write, and superuser (for clients with the user ID 0
). Because the access level determined by the security type is evaluated in this order, you must observe the rules listed:
Rules for access-level parameters in export rules
For a client to obtain the following access levels | These access parameters must match the client's security type |
---|---|
Normal user read-only |
Read-only ( |
Normal user read-write |
Read-only ( |
Superuser read-only |
Read-only ( |
Superuser read-write |
Read-only ( |
The following are valid security types for each of these three access parameters:
-
Any
-
None
-
Never
These security types are not valid for use with the -superuser
parameter:
-
krb5
-
ntlm
-
sys
Rules for access parameter outcomes
If the client's security type … | Then … | ||
---|---|---|---|
Matches a security type specified in the access parameter. |
The client receives access for that level with its own user ID. |
||
Does not match a specified security type, but the access parameter includes the option |
The client receives access for that level and receives the anonymous user with the user ID specified by the |
||
Does not match a security type specified, and the access parameter does not include the option |
The client does not receive any access for that level.
|
Kerberos 5 and Krb5p
Beginning with ONTAP 9, Kerberos 5 authentication with privacy service (krb5p) is supported. The krbp5 authentication mode is secure, and it protects against data tampering and snooping by using checksums to encrypt all traffic between client and server. The ONTAP solution supports 128-bit and 256-bit AES encryption for Kerberos. The privacy service includes verifying the integrity of the received data, authenticating users, and encrypting data before transmission.
The krb5p option is most present in the export policy feature, where it is set as an encryption option. The krb5p authentication method can be used as an authentication parameter, as shown in the following example:
cluster1::> vserver export-policy check-access -vserver vs1 -client-ip 10.22.32.42 -volume flex_vol -authentication-method krb5p -protocol nfs3 -access- type read