Store authentication secrets in access mappings¶

Blueprint: https://blueprints.launchpad.net/manila/+spec/auth-access-keys

In storage systems such as Ceph with a built-in authentication system that generates user credentials, granting share access to a user involves creating a credential, a secret key, that the user henceforth uses to authenticate oneself. This spec proposes to allow drivers of such storage systems to provide secret keys to the users by storing the keys in manila’s database, and exposing them through a user facing API that provides access rule information.

Problem description¶

Manila’s access control APIs and underlying mechanisms were designed for storage backends that rely on external authentication systems to identify clients. The share drivers let the storage back ends know the clients that need to be authorized to access a share.

It was not possible for a driver of a storage back end with its own authentication system to return a credential to the client through a manila API. This meant that the clients had to be provided with the requisite credentials out of band of manila, making the admin and user workflows cumbersome.

Use Cases¶

When a user requests access to a share, a driver will be able to provide an authentication credential, a secret key, to the user through a manila API. For now, cephfs_native driver stands to benefit. It will be able to share the secret key generated by the Ceph storage back end with the user.

Proposed change¶

Receive the access credentials, secret keys, generated by a storage back end for the newly added share rules, as the return value of the back-end driver’s update_access().
Store the secret keys in the ShareAccessMapping model.
Expose them in the manila.share.api.access_get_all API, used to list the access rules of shares.

Alternatives¶

Expect the authentication credentials generated by the storage backend to be shared with the users out of band of manila.

Data model impact¶

Add access_key attribute to the existing ShareAccessMapping model for storing secret keys:
```
access_key = Column(String(255), nullable=True)
```
Add a new DB API, share_access_update_access_key() that updates the attribute access_key of the ShareAccessMapping model.
DB migration:

Upgrade will add the new column access_key to the share_access_map table.

Downgrade will drop the column access_key from the share_access_map table.

REST API impact¶

Add a response parameter access_key of type string that will display the secret key when listing the access rules.

Method: POST

URL: /shares/{share_id}/action Normal response code: 200

Action body:

{
    "access_list": null
}

Example response:

{
    "access_list": [
        {
            "access_level": "rw",
            "state": "active",
            "id": "507bf114-36f2-4f56-8cf4-857985ca87c1",
            "access_type": "cephx",
            "access_to": "alice",
            "access_key": "AQC7fRhXbQXxHxAApF58+AmP6a3zBpwYWNIBbA=="
        }
    ]
}

Driver impact¶

ShareDriver:

A driver’s update_access() may choose to return a dictionary of access_id, access_key as key, value pairs to the ShareManager’s access_helper, for the rules that it added. In the case of recovery/maintenance mode of update_access(), the driver will have to return secret keys for all the access IDs that its ordered to sync, i.e., the access IDs that are in the access_rules parameter.
ShareManager:

The update_access() of the ShareManager’s access_helper calls the update_access() of the driver to add access rules. After adding rules, the driver may return a dictionary, {‘access_id’: ‘access_key’, …}. The update_access of the access_helper will use this dictionary to call the new DB API, share_access_update_access_key() iteratively, to store the secret keys for the various access rules in the share_access_map table.

Security impact¶

The access keys required to access shares will be visible to the users when listing the share access rules.

Notifications impact¶

None

Other end user impact¶

python-manilaclient:

When listing access rules of a share, a new column, access_key will display the access credential (if supplied by a driver). The user will be able to selectively view it.
manila-ui:

A new column access_key will be seen in the RulesTable.

Performance Impact¶

When a driver adds access rules and returns corresponding access keys, the access keys will be updated for the various access IDs in the share_access_map table.

Other deployer impact¶

None

Developer impact¶

Only those drivers that can make use of the feature added by this spec would need to be modified along with the tempest tests run by their CIs.

Implementation¶

Assignee(s)¶

Primary assignee:: rraja

Work Items¶

Enable cephfs_native driver to return access keys when adding share access rules.
Implement core changes to receive access keys from the driver, store them in the share_access_map table, and expose them via access_get_all API.
Allow python-manilaclient and manila-ui to display the access keys.

Dependencies¶

Work will depend on changes to be made to bring back monitoring of access status per access rule instead of per share. This was discussed at the Austin summit, https://etherpad.openstack.org/p/newton-manila-update-access

Testing¶

Update the unit tests in manila, python-manilaclient, and manila-ui repositories.
Update the tempest tests in manila repository.
Update the functional tests in python-manilaclient repository.

Documentation Impact¶

Update the API reference guide.
Update the configuration reference guide mentioning the changes in the cephfs_native driver.
Update the development reference guide.
Update the user guide.

References¶

Mailing list: http://lists.openstack.org/pipermail/openstack-dev/2015-October/077602.html

Store authentication secrets in access mappings