.. This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode =============================================== 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: .. code:: python 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: .. code:: json { "access_list": null } Example response: .. code:: json { "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