Open Stack

On 12/09/17 18:58, Colleen Murphy wrote:
> 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:

Thanks so much for staying on this Colleen, it's tremendously helpful to 
have someone from the core team keeping an eye on it :)

> 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.

OK, there were lots of smart people in the room so I trust that y'all 
made the right decision.

I'd just like to step back for a moment though and ask: how exactly do 
we expect users to make use of Keystone?

When I think about a typical OpenStack user of the near future, they 
looks something like this: there's a team with a handful of developers, 
with maybe one or two devops engineers. This team is responsible for a 
bunch of applications, at various stages in their lifecycles. They work 
in a department with several such teams, in an organisation with several 
such departments. People regularly join or leave the team - whether 
because they join or leave the organisation or just transfer between 
different teams. The applications are deployed with Heat and are at 
least partly self-managing (e.g. they use auto-scaling, or auto-healing, 
or have automated backups, or all of the above), but also require 
occasional manual intervention (beyond just a Heat stack-update). The 
applications may be deployed to a private OpenStack cloud, a public 
OpenStack cloud, or both, with minimal differences in how they work when 
moving back and forth.

(Obviously the beauty of Open Source is that we don't think about only 
one set of users. But I think if we can serve this set of users as a 
baseline then we have built something pretty generically useful.)

So my question is: how do we recommend these users use Keystone? We 
definitely _can_ support them. But the most workable way I can think of 
would be to create a long-lived application user account for each 
project in LDAP/ActiveDirectory/whatever and have that account manage 
the application. Then things will work basically the same way in the 
public cloud, where you also get a user per project. Hopefully some 
auditability is maintained by having Jenkins/Zuul/Solum/whatever do the 
pushing of changes to Heat, although realistically many users will not 
be that sophisticated. Once we have application credentials, the folks 
doing manual intervention would be able to do so in the same way on 
public clouds as on private clouds, without being given the account 
credentials.

Some observations about this scenario:
* The whole user/role infrastructure is completely unused - 'Users' are 
1:1 with projects. We might as well not have built it.
* Having Keystone backed by LDAP/ActiveDirectory is arguably worse than 
useless - it just means there are two different places to set things up 
when creating a project and an extra layer of indirection. (I won't say 
we might as well not have built it, because many organisations have 
compliance rules that, ahem, well let's just say they were developed in 
a different context :)
* We're missing an essential feature of cloud (or even of VPSs): you 
shouldn't need to raise a ticket with IT to be able to deploy a new 
application. Any involvement from them should be asynchronous (e.g. 
setting quotas - although even that is an OpenStack-specific thing: in 
public clouds excessive use is discouraged by _billing_ and in 
non-OpenStack clouds users set their _own_ quotas); we don't want humans 
in the loop.
* AFAIK it's not documented anywhere that this is the way we expect you 
to use OpenStack. Anybody would think it's all about the Users and Roles.

Perhaps someone can suggest a better scenario for this group of users? I 
can't think of one that doesn't involve radical differences between 
public & private clouds (something we're explicitly trying to prevent, 
according to our mission statement), and/or risk total application 
breakage when personnel change.

My worry is that in this and other areas, there's a disconnect between 
the needs of the people whom we say we're building OpenStack for and 
what we're actually building. (Speculation: this might be partly due to 
a tendency to see OpenStack projects as merely an abstraction layer over 
a bunch of vendor technologies - Keystone, as abstraction layer over 
LDAP/ActiveDirectory, Nova as an abstraction layer over 
libvirt/Xen/HyperV, &c. - rather than as components of an integrated 
cloud management service.) I'd like to see us do something like develop 
a bunch of user personae and re-evaluate the conceptual underpinnings 
of... everything, to align them with those needs. Put another way, I 
think looking at features like application credentials in isolation is 
likely to produce locally-optimal decisions rather than a 
globally-optimal design.

cheers,
Zane.