Solum trust creation and usage

This blueprint deals with issues related to uploading DU to glance on behalf of user.

Problem:
-------------
In Solum, DU generation will happen through following workflow actions:
(1) When a user issues 'assembly create' command.
(2) When a user pushes code to their github repository.

We want to ensure that in both these situations Solum uploads DU to glance on user's behalf.

Proposed Solution:
---------------------------
Solum will use either a user token or a trust token to upload DU to glance.

We break down the solution based on the above two workflow actions.

(1) 'assembly create' is the easy case. For this, the user token will be available as part of the context object. So we can directly use it within 'glance image create' call of build_app script.

(2) The git push case is bit involved. In this workflow there is no user token available.
The solution in this case therefore is for the Solum admin user to obtain a trust token from Keystone for <user-id, project-id> and use it to perform actions on a user's behalf.
Generating a trust token is a two step process. First, we need to create a 'trust' between user and Solum admin user. Second, using the created trust, Solum admin user can request a trust token.

Note: Storing user tokens as part of 'assembly create' and using it for git push case is not an option.
The reason being that users may directly perform git push after creating a plan (so no assembly create). Also, for security reasons we don't want to save user tokens.

(asalkeld) they expire, and storing tokens is evil
(devdatta-kulkarni) yep! :)

Proposed code changes:
-----------------------------------
(1) Add Keystone client wrapper to Solum (already present in solum/common/clients.py)

(2) In Keystone client wrapper, add create_trust_context method following the example shown here: (https://github.com/openstack/heat/blob/37f301efd2e32a7edd22f20fd262da57047eec95/heat/common/heat_keystoneclient.py)
See line numbers 221 - 250.

(3) Add code in Keystone client wrapper to request a trust token. Invoke this code from assembly_handler (two steps: create trust, obtains trust token)

(4) Modify builder service's calling of of build_app to run with the environment variables set to use the token (user token or trust token).

(5) Modify 'glance' related steps in build_app to use the tokens passed in (4).

(6) In order to create trust, Solum needs to know the user-id (the trustor) and the roles that the trustor
may want to grant to Solum admin user as part of creating the trust. Currently this information is not available in Solum database. We propose to add it by creating a new table (user) with following columns: <user-id, project-id, roles, plan-id>
This information will be populated when user registers a plan (via app create).

(asalkeld) I thought you just needed the role you need
         we need a role of "solum-glance-storage" and "solum-deployment"
         when we create the trust we create it with these roles
         when we get the trust token we ask for the role we need?
         I don't *think* we need a user table (I hope not)

(devdatta-kulkarni) I think you are right. We need to pass in the list of roles as part
of trust creation. Btw, the user information is already available in all the tables
(all of them have user and project_id columns). So yeah, we don't need a separate user table.

Notes:
(1) Solum can cache the trust token to avoid requesting it for every git push.

(asalkeld) lets not get into the business of caching tokens (early optimization).
(devdatta-kulkarni) sounds good.

(2) Before passing the trust token to build_app, Solum should check whether the token's expiration period has passed or not. If it has then Solum should generate a new trust token, cache it, and then pass it along to build_app.
(3) 'assembly create' flow assumes that the CLI is integrated with Keystone. If not, users will have to perform the step of registering themselves with the Keystone, and then the CLI will need to be modified to send these user tokens to the REST calls.

References:
https://www.enovance.com/fr/blog/5858/role-delegation-in-keystone-trusts