Introduce secure NFS environment support for Cinder

Registered by Glenn M. Gobeli on 2014-07-15

The current Cinder NFS model requires root level access and wide open file permissions, create an insecure NFS environment. This blueprint proposes Cinder modifications to enable the OpenStack user to setup a secure NFS environment wherein root access to the NFS server (backend storage) is squashed, the Cinder NFS process does not run as root, but rather as the configured "stack" user, and NFS file permissions are set to owner and group access only.

This proposal removes root level execution from Cinder when it is RemoteFS based operations. It sets file permissions to 660 rather than 666 and would implement a configuration flag to allow the OpenStack administrator to control whether the new, more strict, permissions are used or to continue using the wide open permissions. The implementation will also require a modification too the emulation service (e.g., qemu) to specify that it run as the stack user and that it not change file ownership: this allows the NFS client-server secure environment operations.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Medium
Drafter:
Glenn M. Gobeli
Direction:
Approved
Assignee:
Glenn M. Gobeli
Definition:
Obsolete
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
milestone icon next
Started by
John Griffith on 2014-07-15
Completed by
Sean McGinnis on 2016-02-01

Related branches

Sprints

Whiteboard

(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.

Gerrit topic: https://review.openstack.org/#q,topic:bp/secure-nfs,n,z

Addressed by: https://review.openstack.org/107693
    NFS Security Enhancements: allows secure NFS environment setup.

Items of concern to consider and discuss:

1) New Installations
New installations will require instructions on how to create a secure NFS environment, which essentially means that the Cloud Administrator needs to:
  a) root squash is enabled on the NFS server
  b) Unix file permissions based access verification is set as a minimum bar of user access to data
  c) appropriate "stack" user credentials are set up, as may be required
  d) the NFS Domain name of the Server is set at the Cinder client side (required for NFSv4)
  e) configure each Nova Compute node's Hypervisor to run as the "stack" user and to not
      modify file ownership (e.g., Libvirt's qemu.conf file)

2) Upgrade Scenarios
Upgrade scenarios will be much like a new installation with the exception of having to deal with pre-existing Cinder created volumes. In this case, the Cloud Administrator must take the same steps as for a new installation (creating a secure NFS environment) and also modify the existing volume ownership and permissions. This is a one-time step that requires manual intervention since the Cinder code cannot modify the NFS Server and, once the server has been properly configured, the Cinder code cannot change file ownership: pre-existing files are owned by root and root will be squashed at the NFS server. Therefore, the Cloud Administrator would:
  a) as a root user on the Cinder node, change ownership of the mounted Cinder volumes
       from "root" to the appropriate "stack" user.
  b) as a root user on the Cinder node, change the file permissions to 660 for the mounted
      Cinder volumes.
These 2 steps would need to be performed prior to changing the NFS server: once the server has been modified the root user would not have access.

Gerrit topic: https://review.openstack.org/#q,topic:bug/1260679,n,z

Note: The concerns over upgrades and how to control the new Secure NFS environment have been addresses via the use of an options flag: "nfs_secure_files".

The "nfs_secure_files" option defaults to "autodetect" and is used in upgrade versus new install scenarios. When "autodetect" is observed during Cinder startup, a check is done to determine if there are existing Cinder volumes: no volumes will use Secure NFS and existing volumes will use current NFS security settings. The Administrator may override the default "autodetect" with "True" or
"False" to get the specific behavior they may desire.

<jdg>
Sorry Glenn, we've just run out of time on this, I'd really like to get this moved forward but I don't see it happening for Juno. I'd REALLY like to focus on this still and have it be one of the first items to go in when Kilo opens up. Let me know if you have any questions.

Thanks!

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.