Allow storage backends such as Ceph with an internal authentication system to return authentication secrets to the users. The secret keys will be generated by the back end when granting access to shares. Change-Id: I935d0523b76bce5274728fb5c7fd00a57d5e4840
6.6 KiB
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 existingShareAccessMapping
model for storing secret keys:= Column(String(255), nullable=True) access_key
Add a new DB API,
share_access_update_access_key()
that updates the attributeaccess_key
of theShareAccessMapping
model.DB migration:
Upgrade will add the new column
access_key
to theshare_access_map
table.Downgrade will drop the column
access_key
from theshare_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 ofaccess_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 ofupdate_access()
, the driver will have to returnsecret keys
for all the access IDs that its ordered to sync, i.e., the access IDs that are in theaccess_rules
parameter.ShareManager:
The
update_access()
of the ShareManager's access_helper calls theupdate_access()
of the driver to add access rules. After adding rules, the driver may return a dictionary, {'access_id': 'access_key', ...}. Theupdate_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 theshare_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 theRulesTable
.
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 viaaccess_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