Open Stack

On Mon, Oct 9, 2017 at 6:39 PM, Zane Bitter <zbitter at redhat.com> wrote:

> 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 :)

No problem :)

>
>
> http://specs.openstack.org/openstack/keystone-specs/specs/ke
>> ystone/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.
>
Another observation - if all the members of the team know the application
user's username and password (which they must, in order to use it to create
application credentials), then the team members who leave the team would
continue to have access to everything the application user has access to,
and also still be able to use the application credentials belonging to the
application user. Like you said, the users are 1:1 with projects and why
even bother.

>
> 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.
>
We can still support almost all the needs of these users, just minus the
100% seamless transition when a human leaves a team. Now it's 95% seamless
with 5% organizational procedures. This is an organizational problem, and
the (admittedly unsatisfying) answer is that we can't solve social problems
with software - but credential rotatability still gets us a lot further.
When a human who owns an application credential leaves the team, the
organization needs to have a process in place to rotate the credential to
another user, hopefully with enough foresight that the applications don't
break. Similarly, when a human who doesn't own any application credential
leaves the team, the credentials they have knowledge about still need to be
rotated. This sucks but it is still a million miles further than having a
static user that can never have its password updated.

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

I would love to see something like this too - maybe this is something we
can organize with operators at the next Forum. I think keystone has a habit
of going off in the weeds in the name of design ideals and leading to a
confusing user experience. On the other hand, a user's ideal experience is
not necessarily going to line up with security concerns, and it is
important to keep those at the forefront of our designs.

I'm still disappointed that this was where we landed. It definitely drops
the ball on one of the primary usability requirements, and it also opens up
more implementation questions (why not just retrofit trusts for this, or
use OAuth2?). But I still think we can move forward on this and create a
useful but relatively secure thing for the users in your scenario.

>
>
> cheers,
> Zane.
>
> Colleen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171010/4849458a/attachment.html>