Open Stack

On 05/16/2017 05:39 AM, Sean Dague wrote:
> On 05/15/2017 10:00 PM, Adrian Turjak wrote:
>>
>>
>> On 16/05/17 13:29, Lance Bragstad wrote:
>>>
>>>
>>> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
>>> <adriant at catalyst.net.nz <mailto:adriant at catalyst.net.nz>> wrote:
> <snip>
>>>     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.
>>>
>>>
>>>     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? 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)?
>>>
>>>
>>> All valid points, but IMO the discussions around API keys didn't set
>>> out to fix deep-rooted issues with policy. We have several specs in
>>> flights across projects to help mitigate the real issues with policy
>>> [0] [1] [2] [3] [4].
>>>
>>> I see an API key implementation as something that provides a cleaner
>>> fit and finish once we've addressed the policy bits. It's also a
>>> familiar concept for application developers, which was the use case
>>> the session was targeting.
>>>
>>> I probably should have laid out the related policy work before jumping
>>> into API keys. We've already committed a bunch of keystone resource to
>>> policy improvements this cycle, but I'm hoping we can work API keys
>>> and policy improvements in parallel.
>>>
>>> [0] https://review.openstack.org/#/c/460344/
>>> [1] https://review.openstack.org/#/c/462733/
>>> [2] https://review.openstack.org/#/c/464763/
>>> [3] https://review.openstack.org/#/c/433037/
>>> [4] https://review.openstack.org/#/c/427872/
>>>
>> I'm well aware of the policy work, and it is fantastic to see it
>> progressing! I can't wait to actually be able to play with that stuff!
>> We've been painstakingly tweaking the json policy files which is a giant
>> mess.
>>
>> I'm just concerned that this feels like a feature we don't really need
>> when really it's just a slight variant of a user with a new auth model
>> (that is really just another flavour of username/password). The sole
>> reason most of the other cloud services have API keys is because a user
>> can't talk to the API directly. OpenStack does not have that problem,
>> users are API keys. So I think what we really need to consider is what
>> exact benefit does API keys actually give us that won't be solved with
>> users and better policy?
>
> The benefits of API key are if it's the same across all deployments, so
> your applications can depend on it working. That means the application
> has to be able to:
>
> 1. provision an API Key with normal user credentials
> 2. set/reduce permissions with that with those same user credentials
> 3. operate with those credentials at the project level (so that when you
> leave, someone else in your dept can take over)
> 4. have all it's resources built in the same project that you are in, so
> API Key created resources could interact with manually created resources.
> 5. revoke at any time (and possibly bake in an expiration to begin with)
>
> #1 means these can't just be users. By the user survey 30% are using
> LDAP/AD, which means the authority to create a user isn't even cloud
> admin level, it's company AD level. It may literally be impossible to do.
>
> #2 means permissions can't be done with roles. Normal users can't create
> roles, and roles don't properly express permissions inherent in them
> either. Even if users started to be able to create roles, that would
> mean an incredible role explosion.
>
> #2 also means this interface can't use policy. Policy an internal
> structure for operators setting allow points, and is a DSL that we
> *really* don't want to make everyone learn every bit of.
>
> #4 means this can't be done with special projects where users could
> create other users using the existing SQL split backend setup in
> keystone (even if they had AD). This is complicated to setup in the
> first place, but if API Key created servers aren't able to get to the
> network that was manually setup in a different tenant, the usefulness is
> limited.
>
>
> This is why the proposal out of the room going forward was some concrete
> steps:
>
> 1) Make a new top level construct of an APPKey that exists within a
> project, that all users can create in projects they are members of.
>
> This immediately solves #1. And even inheriting Member role becomes
> useful because of the revoke facility. There are now a set of
> credentials that are ephemeral enough to back into images / scripts,
> that aren't also getting into your health records or direct deposit at
> your company.
>
> 2) Provide a mechanism to reduce what these APPKeys can do. Policy &
> Roles is actually the wrong approach, those are operator constructs. API
> consuming things understand operations in terms of ("Region1",
> "compute", "/servers", "GET"). Something along those lines would be
> provided as the way to describe permissions from a user.
>
> The complaint is this is a second way of describing permissions. It is.
> But the alternative to teach our entire user base about policy name
> points is ... far less appealing. We should be tailoring this to the
> audience we want to consume it.
>
>
> Yes, these are 2 distinct steps, but I think it's disengenous to say the
> first step is pointless until the second one is done. The first step
> immediately enables a set of use cases that are completely blocked today.

Yes to all of what Sean said- thank you, that summarizes the issue quite 
well.

I was originally of the same POV - "screw this, we already have a 
mechanism for creating users, let's just use it" - but a "user" has a 
bunch of specific connotations which we get entangled with and thus 
remain perpetually unable to make progress on this.

A "User" creating an "API Key" is that user authorizing an 'application' 
to use the API as them. (there is a sticky use case we need to figure 
out in the spec that relates to user lifecycle in shared projects)

FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll 
with that until someone has a better idea. I'm uncrazy about it for two 
reasons:

a) the word "key" implies things to people that may or may not be true 
here. If we do stick with it - we need some REALLY crisp language about 
what it is and what it isn't.

b) Rackspace Public Cloud (and back in the day HP Public Cloud) have a 
thing called by this name. While what's written in the spec is quite 
similar in usage to that construct, I'm wary of re-using the name 
without the semantics actually being fully the same for risk of user 
confusion. "This uses api-key... which one?" Sean's email uses "APPKey" 
instead of "APIKey" - which may be a better term. Maybe just 
"ApplicationAuthorization"?

Anyway - I will say that this is an area where the discussion at the 
Forum was very helpful in expanding my understanding and changing my 
opinion - to the point where I'm now happy helping drive the spec. Score 
one for the Forum!