<div dir="ltr"><div>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:</div><div><br></div><div><a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/application-credentials.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/application-credentials.html</a><br></div><div><br></div><div>Attached are images of the whiteboarded notes.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>If I've misremembered or omitted anything important here please correct me.</div><div><br></div><div>Colleen</div><div><br></div><div>[0] <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html">https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/implemented/service-tokens.html</a></div><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div>