About Security

Access Control

The File Storage service uses four different layers of access control. Each layer has its own authorization entities and methods which are separate from the other layers.


Watch a video about security in File Storage.

The Oracle Cloud Infrastructure (OCI) policy layer uses policies to control what users can do within Oracle Cloud Infrastructure, such as creating instances, a VCN and its security rules, mount targets, and file systems.

The Network security layer controls which instance IP addresses or CIDR blocks can connect to a host file system. It uses VCN security list rules to allow or deny traffic to the mount target, and therefore access to any associated file system.

The NFS export option layer is a method of applying access control per-file system export based on source IP address that bridges the Network Security layer and the NFS v.3 Unix Security layer.

The NFS v.3 Unix security layer controls what users can do on the instance, such as installing applications, creating directories, mounting external file systems by a local mount point, and reading and writing files.

This security layer... Uses these... To control actions like...
Oracle Cloud Infrastructure Identity and Access Management Users and policies Creating instances and VCNs. Creating, listing, and associating file systems and mount targets.
Network security IP addresses, CIDR blocks, security lists Connecting the client instance to the mount target.
NFS v.3 Unix security Unix users, file mode bits Mounting file systems, reading and writing files.
NFS export options File system exports, IP addresses, Unix users Privileged source port connection, reading and writing files, and limiting root user access on a per-file system basis.

Oracle Cloud Infrastructure Identity and Access Management

You can create users and groups in Oracle Cloud Infrastructure. Then, you can use policies to specify which users and groups can create, access, or modify resources such as file systems, mount targets, snapshots, and export options within . See Overview of Identity and Access Management to learn more about how to set up access.

Network Security

The network security layer allows you to use VCN network security groups (NSGs) and security rules to block the appropriate ports from specific IP addresses and CIDR blocks and restrict host access. However, it's on an ‘all or nothing’ basis - the client either can or cannot access the mount target, and therefore all file systems associated with it. See Ways to Secure Your Network for general information about VCN security groups, security lists, and rules. See Configuring VCN Security Rules for File Storage for specific information about the security rules necessary for File Storage.

NFS v.3 Unix security

File Storage service supports the AUTH_UNIX style of authentication and permission checking for remote NFS client requests. When mounting file systems, we recommend that you use the -nosuid option. This option disables set-user-identifier or set-group-identifier bits. Remote users are prevented from gaining higher privileges using a setuid program. For more information, see Mounting File Systems.

Remember that users in UNIX aren’t the same as users in Oracle Cloud Infrastructure - they’re not linked or associated in any way. The Oracle Cloud Infrastructure policy layer doesn’t govern anything that happens inside the file system, the UNIX security layer does. Conversely, the UNIX security layer doesn’t govern creating file systems or mount targets in Oracle Cloud Infrastructure.

File Storage does not support file level Access Control Lists (ACLs). Only user, group, and world permissions are supported. File Storage uses the NFSv3 protocol, which doesn't include support for ACLs. setfacl fails on mounted file systems. getfacl returns only standard permissions.


Some implementations might extend the NFSv3 protocol and add support for ACLs as part of a separate rpc program.
SETFACL error example

This example shows an example of a setfacl error:

[opc@example setfacl_testing]$ ls -ld test
drwxr--r--. 2 opc opc 0 Jul  2 10:31 test
[opc@example setfacl_testing]$ setfacl -m u:applmgr:r test
setfacl: test: Operation not supported
[opc@example setfacl_testing]$ 
[opc@example setfacl_testing]$ getfacl test
# file: test
# owner: opc
# group: opc
[opc@example setfacl_testing]$

NFS export options

NFS export options are a method of applying access control at both the network security layer and the NFS v.3 Unix security layer. You can use NFS export options to limit access levels by IP addresses or CIDR blocks connecting to multiple file systems through exports of an associated mount target. Access can be restricted so that each client’s file system is inaccessible and invisible to the other, allowing for managed hosted environment security. Moreover, you can set NFS v.3 Unix security permissions for read-only, read/write, or root-squash for your file systems. See Working with NFS Export Options for more information.


Within Oracle Cloud Infrastructure

All data is encrypted at rest. You can leave all encryption-related matters to Oracle, or you can choose to manage your own encryption using the Oracle Cloud Infrastructure Vault (KMS) service. You can use KMS to create master encryption keys and data encryption keys, rotate keys to generate new cryptographic material, enable or disable keys for use in cryptographic operations, assign keys to file systems, and use keys for encryption and decryption.

Currently, only symmetric Advanced Encryption Standard (AES) keys are supported for file system encryption.
For more information, see Overview of Vault.

Between Instances and Mounted File Systems

In-transit encryption provides a way to secure your data between instances and mounted file systems using TLS v. 1.2 (Transport Layer Security) encryption.

In-transit encryption is enabled by installing a client package on your Linux instance or stunnel on Windows.

The Linux package creates an NFS endpoint, network namespace, and network interface. A forwarder process receives requests from the NFS client, encrypts them and sends them to the mount target using a TLS tunnel. Installing and configuring stunnel similarly encrypts requests and uses a TLS tunnel.

For more information, see Using In-transit Encryption.