Open Stack

While it's fresh in our minds, I wanted to write up a short recap of where
we landed in the Application Credentials discussion in the BM/VM room
today. For convenience the (as of yet unrevised) spec is here:

http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/application-credentials.html

Attached are images of the whiteboarded notes.

On the contentious question of the lifecycle of an application credential,
we re-landed in the same place we found ourselves in when the spec
originally landed, which is that the credential becomes invalid when its
creating user is disabled or deleted. The risk involved in allowing a
credential to continue to be valid after its creating user has been
disabled is not really surmountable, and we are basically giving up on this
feature. The benefits we still get from not having to embed user passwords
in config files, especially for LDAP or federated users, is still a vast
improvement over the situation today, as is the ability to rotate
credentials.

In other topics, there are two different types of access control that we
would like to be grantable to an application credential. One is managed by
traditional keystone roles, and the other would map to REST calls (this is
alluded to in a brief note in the spec but we have no details about it
yet). A question that was brought up today was that given the currently sad
status of default roles in keystone, should we start with the
REST-call-based access control delegation first? The answer is that
application credentials must still be based on keystone roles simply
because that is the basis for access control in keystone today and
circumventing that could lead to a user creating a credential that has more
power than the user's role allows. However, we can do this in a mostly
non-user-configurable way: the application credential just receives the
role on the project that the creating user is scoped to at creation time.
This fits nicely when we ask what happens when global roles become a thing,
since the spec is currently geared entirely toward project-scoped
credentials: if and when global roles become a reality, we can still say
that an application credential receives the scope it was created under,
whether that is global or project. Optionally, then, we can let the user
assign the credential any other roles that the user has on that project,
remembering that there is no implicit hierarchy in roles, i.e. member does
not imply observer, so a user with only a member role can't grant the
credential the observer role even though functionally we know observer
ought to have lower privileges than member.

When we do start addressing the REST-endpoint model of access control, we
start having some deja-vu from the questions we have been asking around
policy. For example, what do we do about the actions API in nova, for which
we may want to impose different restrictions based on the request body? The
answer is simply that we're not going to solve it for the application
credential case (unrelated to the solution for the policy case). Relatedly,
what happens on, for example, a server boot request, which at the front end
is just a nova request but in reality involves multiple services? The
answer there is, much unlike our current policy handling, the access
control is only defined at the user entry point, e.g. POST /servers, and
therefore implicitly allows such things as GET /images. The reason this
will work without being massively insecure is that we have already laid the
groundwork for service tokens[0], creating a trust association between
services, and so we can expand on that to allow application credentials to
complete such complex operations without defining at a miniscule level
their allowed actions.

An interesting use case for heat came up that we hadn't thought about
before, which is that heat needs to be able to create application
credentials for the servers it creates so that servers can make API calls.
This is specifically disallowed in the current version of the spec. It was
brought up that heat could potentially abuse the token returned from an
application credential authentication request, which at that point is just
a regular user token, to then generate further application credentials,
making our imposed limitations useless. Rather than leaving this open for
abuse, we need to manage this use case in a secure way, so we need clarify
how these limitations are imposed by annotating tokens when they are
created by an application credential, and then adding a policy mechanism to
specifically allow heat to create application credentials.

If I've misremembered or omitted anything important here please correct me.

Colleen

[0]
https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170913/99b78643/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20170912_104014.jpg
Type: image/jpeg
Size: 1162271 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170913/99b78643/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20170912_104025.jpg
Type: image/jpeg
Size: 1105402 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170913/99b78643/attachment-0003.jpg>