Announcing NFS Export Options for File Storage

Mona Khabazan
Principal Product Manager

Hi, I am Mona Khabazan, Product Manager for Oracle Cloud Infrastructure File Storage. At the beginning of this year we launched File Storage, a brand-new service at an extremely high scale, to support enterprise cloud strategies. File Storage provides persistent shared file systems in the cloud that are highly available, highly durable, and fully managed. With File Storage, you can start small and grow up to 8 exabyte in every file system without any upfront provisioning or allocation.

File Storage is needed by nearly every enterprise application that wants to move its workloads into the cloud. We built this service on a distributed architecture to provide full elasticity in the cloud to give you a competitive advantage. You don't have to worry about storage maintenance and capacity management; instead you can focus on your business needs and simplify your operations by leveraging from File Storage service.

NFS Export Options

We understood your need for a more granular access and security controls on a per file system basis to enable multi-tenant environments. So, we are now announcing NFS Export Options to enable you to set permissions on your file systems for Read or Read/Write access, limit root user access, require connection from a privileged port, or completely deny access to some clients.

How it works

When you create a file system and associated mount target, the export options for that file system are set to the following defaults:

Source: (All)
Require Privileged Source Port: false
Access: Read_Write
Identity Squash: None

The default settings allow full access for all NFS client source connections. These defaults can be changed for more granular access control, even though Mount Targets in File Storage are not accessible from the Internet. By default, your file system is visible only to all the hosts that are in the Mount Target's virtual cloud network (VCN) or peered to that VCN. Additionally, VCN security rules apply another layer of control. Now by using NFS Export Options, you can set additional limits on clients' ability to connect to your file systems to view or write data, based on the clients’ IP addresses.

Managing which clients have access to your file systems is straightforward. For each file system, simply set the Source parameter to define which clients should access which file systems. Clients that are not listed do not have visibility into your file systems.

Try It for Yourself

Let’s say that you have three clients that are sharing one mount target, but each client has its own file system. In this scenario, you want to set them up so that they can’t access each other's data, as follows:

  • Client A is assigned to CIDR block and should have Read/Write access to File system A but not File System B.
  • Client B is assigned to CIDR block and should have Read/Write access to File System B but not File System A.
  • Client C is assigned to CIDR block and should not have access to either File System A or B.



Because Client A and Client B access the mount target from different CIDR blocks, you can set the client options for both file system exports to allow access to only a single CIDR block.

To create this access:

Set file system A to allow Read/Write access only to Client A, who is assigned to CIDR block Because neither Client B nor Client C is included in this CIDR block, they cannot access file system A.

oci fs export update --export-id <File_system_A_export_ID> --export-options '[{"source":"","require-privileged-source-port":"true","access":"READ_WRITE","identity-squash":"NONE","anonymous-uid":"65534","anonymous-gid":"65534"}]' 

Next, set file system B to allow Read/Write access only to Client B, who is assigned to CIDR block Because neither Client A nor Client C is included in this CIDR block, they cannot access file system B.

oci fs export update --export-id <File_system_B_export_ID> --export-options '[{"source":" ","require-privileged-source-port":"true","access":"READ_WRITE","identity-squash":"NONE","anonymous-uid":"65534","anonymous-gid":"65534"}]'

Because you did not include Client C's CIDR block in any of these export options, neither file system A nor file system B is visible to Client C.

Now, let’s say in a different scenario, to increase security you want to limit root user's privileges when connecting to file system D. Use the Identity Squash option to remap root users to UID and GID 65534. In UNIX-like systems, this combination is reserved for 'nobody', which is a user with no system privileges.

oci fs export update --export-id <File_System_D_export_OCID> --export-options '[{"source":"","require-privileged-source-port":"true","access":"READ_WRITE","identitysquash":"ROOT","anonymousuid":"65534","anonymousgid":"65534"}]'

CLI, SDK, or Terraform

Here I have demonstrated just two scenarios using the CLI. For more scenarios and instructions on how to achieve the same control with the SDK or Terraform, see Working with NFS Export Options. For more information about how different types of security work together in your file system, see About Security.

We continue to strive to find areas of differentiation in storage technology that enterprises need most to give you a competitive advantage. Bring your storage-hungry workloads, and send me your thoughts on how we can continue to improve File Storage. There is ample opportunity ahead of us; we’re just getting started. 

Mona Khabazan

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.