Add support for PKI Certificate (aka X.509 Certificate) based access_type in Manila

Registered by Deepak C Shetty on 2014-07-18

Today Manila only supports `ip` and `sid` based access_types to the shares as
part of its access_allow API/CLI. Storage backends that support certificate
based access_type to a share cannot be used unless they support either `ip` or
`sid` based access. The existing access types aren't very secure as they don't
encrypt the data on the wire. Adding certificate based access type support will
provide storage backends that support it to provide a secure way of provisioning
the shares to the instances.

Certificate based access can also be used along with neutron networking to
implement a multi-tenant driver for storage backends that don't support
multi-tenancy natively.

For eg: GlusterFS doesn't support multi-tenancy natively, but supports
certificate based access to its shares. We can use neutron to create tenant
specific subnets (eg: VLAN based) and provide secure access to the share using
certificate based access. Only the tenant(s) having the certificate(s) will be
allowed to access and hence mount the share.

NOTE: Per the IRC discussions @
http://eavesdrop.openstack.org/meetings/manila/2014/manila.2014-07-24-15.01.log.html (15:27:19 onwards)

Certificate based trust setup between instances and backend is out-of-band of Manila. The storage admin and/or openstack deployer should have setup the backend to use SSL based auth as a pre-requisite.

High level tasks :

* Add support for new access_type (`cert` maybe) in access_allow API

* In access_allow, if access_type = cert

  * Enable the SSL CN (aka common name) that is allowed to access the backend (This will be backend specific work)

* In access_deny

  * Remove the SSL CN that is allowed to access the backend (This will be backend specific work)

Overview about PKI can be found at [1].
Overview about openssl can be found at [2]
How to use openssl to create keys, certificates etc can be found at [3] and [4]

[1]: http://en.wikipedia.org/wiki/X509
[2]: http://wiki.openssl.org/index.php/Main_Page
[3]: http://www.openssl.org/docs/HOWTO/keys.txt
[4]: http://www.openssl.org/docs/HOWTO/certificates.txt

Blueprint information

Status:
Complete
Approver:
Ben Swartzlander
Priority:
Low
Drafter:
Deepak C Shetty
Direction:
Approved
Assignee:
Deepak C Shetty
Definition:
Approved
Series goal:
Proposed for juno
Implementation:
Implemented
Milestone target:
milestone icon juno-3
Started by
Deepak C Shetty on 2014-09-04
Completed by
Deepak C Shetty on 2014-09-05

Related branches

Sprints

Whiteboard

scottda (Scott D'Angelo): Will cert base access work with the generic driver reference implementation? If not, should this be an extension?

dpkshetty (Deepak C Shetty): scottda, looking at manila/api/contrib/share_actions.py, it seems all share actions (incl. access_allow) is implemented as manila extensions, so any new access_type to access_allow API will need to be implemented as extension only.

vponomaryov (Valeriy Ponomaryov):
I have several questions:

1) quote "Certificate based access can also be used along with neutron networking to
implement a multi-tenant driver for storage backends that don't support
multi-tenancy natively." - How exactly certificate based access can be used for implementation of 'multi-tenancy'?

2) Can it be implemented within Generic driver? If yes, how?

3) If it can not be implemented in Generic driver, how is it planned to be tested?

dpkshetty (Deepak C Shetty) -> vponomaryov :

GlusterFS provides IP based filtering / access controls only. So we cannot distinguish between 2 tenants if they happen to have the same IP (which is legal). Hence on top of IP based access control, we plan to use certificate based authentication to ensure that the IP (tenant) having the right certificate only can access the share.

As of now, I don't think this access_type can be supported in the generic driver. As said in the desc. this is a backend specific feature and GlusterFS is one example backend that supports this access_type, so it currently makes sense for GlusterFS but the implementation will extend the existing access_type in access_allow API, thus allowing other backends in future to exploit it if they support it.

Do you mean unit tests or tempest ones ? We can add both. I added testcases in the workitems below.

----------------------------------------------

Some more details on how we plan to implement this:

1) The existing service VM approach won't be used here. Tenants will directly connect to the backend share using the SSL Certificate based access enabled on both the client and server backends. A per tenant subnet will be created and tenant would be configured to use SSL based authentication.

2) For this to work, as part of the access allow with cert type the following orchestration needs to be done ( This is backend specific and the below is for GlusterFS backend as example )

    2.1) Setup a new subnet between the tenant and the server backend

    2.2) Create the client and server certificates. Sign the client's certificate usign server's certificate (aka depth=1 in SSL lingo)

    2.3) Push the client's certificate into the instance requesting share access. Push the server's certificate onto the server backend (This could mean copying the server cerificates to all the nodes that form the server backend (storage cluster))

    2.4) Enable the mutual trust between the instance and server by copying the server's certificate into the local CA of the instance. Server's certificate would be self-signed and hence always trusted on the server side.

    2.5) At this point, we can return success from allow_access & only the instance(s) having the signed certificate will be able to mount the share. For others, the mount will fail with "Unable to authenticate" error.

    2.6) Remove the client certificates (or investigate using revoke access list) as part of access_deny flow.

3) Cert based access type is supported by GlusterFS for the glusterfs native protocol only, so the above applies to that case only.
For NFS and CIFS we follow the regular service VM based approach.

ameade (Alex Meade): This makes a ton of sense to me, couple things I want to bring up though. Manila actually doesn't support 'sid' access_type and the code referencing sids currently doesn't work and is planned to be removed IIUC. Also, access groups are currently under development (https://blueprints.launchpad.net/manila/+spec/access-groups) and will be affected/affect this bp.

vponomaryov (Valeriy Ponomaryov) -> ameade :
Manila actually does support sid rules. There are two parts of working rules - implementation of interface and backend implementation. So, first one is single point and it is implemented, second - one realisation per backend. We can say only one thing - that 'sid' rule is supported only by Cmode driver for the moment and if we want use these rules, we should configure security-service client with security-service entities, attached to share-network entities.

vponomaryov (Valeriy Ponomaryov) -> dpkshetty :
Is it correct that in case of GlusterFS, any tenant has net connectivity to whole backend where all shares of cluster are stored and only cert-based-access-rules will be some kind of gates for mount possibility?

dpkshetty (Deepak C Shetty) -> vponomaryov :
That depends on how the GlusterFS volumes are mapped to the Manila shares. Currently we plan to have 1 share = 1 glusterfs volume, and create subnets between tenant and shares, so the tenants can only see their own shares. In future we may plan to support 1 share = 1 subdir inside glusterfs volume, wherein tenants has connectivity to the whole cluster but will only be able to access shares that are assigned / allowed for them.

scottda (Scott D'Angelo) How will you push the certs to the client instance? It is a grey area at this point, to access the instance itself and make changes (I believe a similar problem exists for modifying the instance /etc/fstab for mounting shares).

dpkshetty (Deepak C Shetty) -> scottda:
Some potential approaches could be to use some kind of cloud-init style scripts to pull the client certs in or have the admin create customized images with the certs pre-created inside or if the instance is already booted, have the admin setup the certs as a pre-req. Whatever method we use, this needs to happen out of band of the manila cli flow and needs to be documented.
I don't think we need to worry about /etc/fstab, either the admin or the instance user should do it, if they care about automounts. Mounting the share inside the instance is under instance control AFAIU, not in manila control.

Gerrit topic: https://review.openstack.org/#q,topic:cert-based-access-type,n,z

Addressed by: https://review.openstack.org/114736
    WIP: Add support for cert-based access type

Addressed by: https://review.openstack.org/116859
    Add support for glusterfs native protocol driver

Manilaclient change:
    https://review.openstack.org/#/c/114737/

(?)

Work Items

Work items:
1) Add support for new access_type (cert maybe) in access_allow API : DONE
2) Add support for new access_type (cert maybe) in manilaclient : DONE
3) In access_allow, if access_type = cert, enable the SSL CN that is allowed access to the share (This will be backend specific work). : DONE
4) In access_deny, remove the SSL CN that is allowed to access the share (This will be backend specific work) : DONE
5) Add testcases for the above scenarios : DONE

This blueprint contains Public information 
Everyone can see this information.