Open Stack

On 15/05/17 20:07, Adrian Turjak wrote:
>
> On 16/05/17 01:09, Lance Bragstad wrote:
>>
>>
>> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mordred at inaugust.com
>> <mailto:mordred at inaugust.com>> wrote:
>>
>>     On 05/11/2017 02:32 PM, Lance Bragstad wrote:
>>
>>         Hey all,
>>
>>         One of the Baremetal/VM sessions at the summit focused on what
>>         we need
>>         to do to make OpenStack more consumable for application
>>         developers [0].
>>         As a group we recognized the need for application specific
>>         passwords or
>>         API keys and nearly everyone (above 85% is my best guess) in
>>         the session
>>         thought it was an important thing to pursue. The API
>>         key/application-specific password specification is up for
>>         review [1].
>>
>>         The problem is that with all the recent churn in the keystone
>>         project,
>>         we don't really have the capacity to commit to this for the
>>         cycle. As a
>>         project, we're still working through what we've committed to
>>         for Pike
>>         before the OSIC fallout. It was suggested that we reach out to
>>         the PWG
>>         to see if this is something we can get some help on from a
>>         keystone
>>         development perspective. Let's use this thread to see if there
>>         is anyway
>>         we can better enable the community through API
>>         keys/application-specific
>>         passwords by seeing if anyone can contribute resources to this
>>         effort.
>>
>>
>>     In the session, I signed up to help get the spec across the finish
>>     line. I'm also going to do my best to write up something
>>     resembling a user story so that we're all on the same page about
>>     what this is, what it isn't and what comes next.
>>
>>
>> Thanks Monty. If you have questions about the current proposal, Ron
>> might be lingering in IRC (rderose). David (dstanek) was also
>> documenting his perspective in another spec [0].
>>
>>
>> [0] https://review.openstack.org/#/c/440593/
>>
>>
>
> Based on the specs that are currently up in Keystone-specs, I would
> highly recommend not doing this per user.
>
> The scenario I imagine is you have a sysadmin at a company who created a
> ton of these for various jobs and then leaves. The company then needs to
> keep his user account around, or create tons of new API keys, and then
> disable his user once all the scripts he had keys for are replaced. Or
> more often then not, disable his user and then cry as everything breaks
> and no one really knows why or no one fully documented it all, or didn't
> read the docs. Keeping them per project and unrelated to the user makes
> more sense, as then someone else on your team can regenerate the secrets
> for the specific Keys as they want. Sure we can advise them to use
> generic user accounts within which to create these API keys but that
> implies password sharing which is bad.

Yes, absolutely. Like other OpenStack resources, API keys need to belong 
to the project, not the user.

> That said, I'm curious why we would make these as a thing separate to
> users. In reality, if you can create users, you can create API specific
> users. Would this be a different authentication mechanism? Why? Why not
> just continue the work on better access control and let people create
> users for this. Because lets be honest, isn't a user already an API key?

Essentially, with the exception that an API key only gets you 
authenticated to OpenStack, whereas a user's 'key' (password) probably 
also gets them into a lot of other things.

I want to be clear though: if that's the only benefit we get from API 
keys then we are *failing*. We must put fine-grained authorisation 
control in the end user's hands to actually solve the problem.

> The issue (and the Ron's spec mentions this) is a user having too much
> access, how would this fix that when the issue is that we don't have
> fine grained policy in the first place? How does a new auth mechanism
> fix that? Both specs mention roles so I assume it really doesn't. If we
> had fine grained policy we could just create users specific to a service
> with only the roles it needs, and the same problem is solved without any
> special API, new auth, or different 'user-lite' object model. It feels
> like this is trying to solve an issue that is better solved by fixing
> the existing problems.
>
> I like the idea behind these specs, but... I'm curious what exactly they
> are trying to solve. Not to mention if you wanted to automate anything
> larger such as creating sub-projects and setting up a basic network for
> each new developer to get access to your team, this wouldn't work unless
> you could have your API key inherit to subprojects or something more
> complex, at which point they may as well be users. Users already work
> for all of this, why reinvent the wheel when really the issue isn't the
> wheel itself, but the steering mechanism (access control/policy in this
> case)?

This was my assumption to start with as well - create a separate domain 
backed by a DB, allow all users (not just admins) to create 'user' 
accounts in that domain and assign roles on the current project that 
they themselves hold to those accounts. That combined with a sane 
default policy (where not every role gives you total access to the 
projects) gets you to a point where you have application accounts 
associated with a project but with no permissions to do anything. From 
there you can add in a standard way of allowing the (actual) user to 
delegate additional permissions to the account that are not captured in 
policy.

Note that *either* way you end up with two authorisation mechanisms: 
policy.json for operators and something else that end users can control. 
Both mechanisms _could_ rely on Keystone roles[1], but likely at the 
cost of an explosion of proliferating roles.

TBH I don't care too much which way we do it as long as it gets done :)

One point that was made in the session was that various organisations 
may have strict policies or compliance requirements around how 'users' 
are authenticated, and that we can pre-emptively avoid a world of hurt 
for some of them by creating a primitive that is named literally 
anything but 'user'.

A User-based system could possibly get operator-deployed applications 
(i.e. Trove/Sahara/Magnum) to where they'd need to be quicker - which is 
a consideration because this is a blocker for Kuryr - but I think they'd 
end up in the same place. (I'd be more confident if we had the 
service-locked VMs feature in Nova.)

The bottom line seems to be that it's a trade-off between having 
different authorisation primitives for operators and users, or an 
explosion of Keystone roles.

cheers,
Zane.

[1] Adam's talk 
https://www.openstack.org/videos/boston-2017/per-api-role-based-access-control 
offered one such mechanism. Everybody in this thread should probably 
watch that.