reimplement machine tokens with api key and secret

[loomis]

Reimplement the "machine cookies" so that they use API key and secret authentication. A new set of credentials should be created for each run and deleted when the run has terminated. The clear text secret must be transmitted to all of the nodes in an application to allow them to communicate with the server.

When doing this work, whether to extend the API key and secret functionality to include limits on the scope of the credentials should be evaluated.

[konstan]

• @loomis suggested include/exclude pattern to scope access to different resources.

{'include': [<list of accessible resources>],
 'exclude': [<list of forbidden resources>]}
# One of the two lists should be empty, but not both.  This always forces application of restrictions.
# Resource path should start with '/' and can not be '/'.

• Evaluate an option for include/exclude to contain operations.

{'include': [{'/run/1-2-3': ['delete', 'edit', 'view']}, {'/user/username': ['view']}],
 'exclude': []}
# Only two resources are allowed; access to all other resources is forbidden.
# Allowed operations on the resources are explicitly defined ('view' is there by default and can be omitted).

# Forbid editing of /billing and forbid any operation on /configuration; allow all the rest depending on the user's ACLs.
{'include': [],
 'exclude': [{'/billing': ['edit'], '/configuration': []}]}

• The token generated from the api key/secret should contain

  • type: api-key
  • include/exclude map (this means that the access to resources with the token is fixed at the time of its generation (although the api key/secret credential resource is editable and can change, potentially allowing to generate another token with different access restrictions))

• The token generated with the key/secret (type api-key) should not allow

  • POST on /credentials
  • editing of any for the the user credentials (as now they are editable)

[loomis]

@konstan Should the paths be specified with regular expressions or just fixed "starts with" expressions? Use consistently the HTTP or the CIMI operations in the lists. Probably the direct HTTP operations are clearer because we've overloaded PUT for both querying and editing, although not on the same resources.

[konstan]

@loomis

Should the paths be specified with regular expressions or just fixed "starts with" expressions?

Lets start with "starts with" and then see if it's enough or not. OK?

Use consistently the HTTP or the CIMI operations in the lists. Probably the direct HTTP operations are clearer because we've overloaded PUT for both querying and editing, although not on the same resources.

I was going to propose to use CIMI operations, that is why used 'delete', 'edit', 'view' in an example. At the same time, POST on /credentials and PUT on /credentials/<uuid> were intended to be evaluated based on the type of the token and even before looking into other metadata of the token. This can act as the additional protection mechanism by resources.

Now I see that HTTP verbs would be a better choice.

So,

{'include': [{'/run/1-2-3': ['DELETE', 'PUT', 'GET']}, {'/user/username': ['GET']}],
 'exclude': []}

{'include': [],
 'exclude': [{'/billing': ['PUT'], '/configuration': []}]}

[konstan]

• substitute machine cookie with api key/secret when launching deployments (SS) substitute machine cookie with api key/secret when launching deployments #1386
• update client to use api key/secret (client) update client to use api key/secret SlipStreamClient#380
• update api key/secret generation to accept resource scoping (cimi) update api key/secret generation to accept resource scoping #1387
• update resource authz to enforce resource scope limits provided with the tokens generated by the api key/secret authn (cimi, SS) update resource authz to enforce resource scope limits provided with the tokens generated by the api key/secret authn #1388