Open Stack

On Tue, May 16, 2017 at 8:54 AM, Monty Taylor <mordred at inaugust.com> wrote:

> 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"?
>

++

The only strong opinion I have (yet) is that the name accurately represents
what it does. Calling something one thing and having it behave differently,
with respect to other known models, is the case I want to avoid.


>
> 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!
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/73fd7928/attachment.html>