Use this topic to learn about controlling access to Cloud Filestore instances.
Cloud Filestore doesn't support Kerberos for securing access to Cloud Filestore instances. Use the Linux and Cloud Identity and Access Management (IAM) options described below instead.
Fileshare export settings
A Cloud Filestore fileshare is assigned fixed /etc/exports
settings, as follows:
- The client list, which identifies the clients allowed to connect to the fileshare, is
composed of all internal IP addresses in the VPC network you selected for the
Cloud Filestore instance. Internal IP addresses are those in ranges
10.0.0.0/8,172.16.0.0/12, and192.168.0.0/16per RFC 1918. - The
rwoption is used, so the fileshare is read-write. - The user ID mapping option
no_root_squashis used, so all users and groups, including the root user, are expected to be the same on both the Cloud Filestore instance and the client. - All other options use the
/etc/exportsdefaults.
You can't change fileshare export settings.
Fileshare permissions
When you create a Cloud Filestore instance, the fileshare for that instance
has default Unix permissions of rwxr-xr-x, octal notation 755. These permissions mean
that on a Cloud Filestore instance, only root users
on connected clients have read/write access to the fileshare. Other users have only read access by default,
but client root users can change permissions and owners.
Configuring access on a fileshare
When mounting a Cloud Filestore fileshare on a client, you can use options for the
mount command and settings in the
/etc/fstab file to determine whether the
mounted fileshare is writable and if files can be executed on it. After mounting the fileshare,
you can use standard Linux commands like chmod,
and setfacl to set file and fileshare permissions.
Setting consistent permissions
We strongly recommend that you set consistent permissions for each user on all clients that connect to the same Cloud Filestore instance, because of an issue that occurs when:
- A fileshare is mounted on more than one client, and
- A user has root permission on one client but not the others
The user can upload a file with the setuid bit set from the client where they have
root access, which then allows them to execute the file as root on any other client
where they have at least read permission. This is because the setuid bit allows
a user to execute a file using the permissions of the
file owner, in this case root.
IAM roles and permissions
You grant access to Cloud Filestore operations by using Cloud Identity and Access Management (IAM) roles.
IAM permissions only control access to Cloud Filestore operations, like creating a Cloud Filestore instance. Access to operations on the Cloud Filestore fileshare, like read or execute, are determined by Linux permissions.
Using Cloud Filestore roles
You can use the Cloud Filestore Editor and Cloud Filestore Viewer roles to grant Cloud Filestore permissions to users. If you prefer, you can also use primitive roles for this purpose.
Use the following table to see the Cloud Filestore permissions associated with Cloud Filestore roles.
| Permission | Action | Cloud Filestore Editor role | Cloud Filestore Viewer role |
| file.locations.get | Get information about a specific location supported by this service. | X | X |
| file.locations.list | List information about the supported locations for this service. | X | X |
| file.instances.create | Create a Cloud Filestore instance. | X | |
| file.instances.update | Update a Cloud Filestore instance. | X | |
| file.instances.delete | Delete a Cloud Filestore instance. | X | |
| file.instances.get | Get details about a specific Cloud Filestore instance. | X | X |
| file.instances.list | List the Cloud Filestore instances in the project. | X | X |
| file.operations.get | Get the status of a Cloud Filestore instance operation. | X | X |
| file.operations.list | List Cloud Filestore instance operations. | X | X |
| file.operations.cancel | Cancel a Cloud Filestore instance operation. | X | |
| file.operations.delete | Delete a Cloud Filestore instance operation. | X |
Using primitive roles
Cloud Filestore permissions are also associated with the IAM primitive roles of owner, editor, and viewer. You can use these roles in addition to the Cloud Filestore roles to grant Cloud Filestore permissions to users.
Use the following table to see the Cloud Filestore permissions associated with primitive roles.
| Permission | Action | Project Owner role | Project Editor role | Project Viewer role |
| file.locations.get | Get information about a specific location supported by this service. | X | X | X |
| file.locations.list | List information about the supported locations for this service. | X | X | X |
| file.instances.create | Create a Cloud Filestore instance. | X | X | |
| file.instances.update | Update a Cloud Filestore instance. | X | X | |
| file.instances.delete | Delete a Cloud Filestore instance. | X | X | |
| file.instances.get | Get details about a specific Cloud Filestore instance. | X | X | X |
| file.instances.list | List the Cloud Filestore instances in the project. | X | X | X |
| file.operations.get | Get the status of a Cloud Filestore instance operation. | X | X | X |
| file.operations.list | List Cloud Filestore instance operations. | X | X | X |
| file.operations.cancel | Cancel a Cloud Filestore instance operation. | X | X | |
| file.operations.delete | Delete a Cloud Filestore instance operation. | X | X |
Custom roles
If the predefined IAM roles don't meet your needs, you can define custom role
with permissions that you specify. To support this, IAM offers
custom roles.
When you create custom roles for Cloud Filestore, make sure that you
include both resourcemanager.projects.get and resourcemanager.projects.list
so that the role has permission to query project resources. Otherwise, the
GCP console won't function correctly for Cloud Filestore.
