Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Wed, May 17, 2017 at 12:21 AM, Monty Taylor  wrote:

> On 05/16/2017 02:44 PM, Sean Dague wrote:
>
>> On 05/16/2017 03:40 PM, Monty Taylor wrote:
>>
>>> On 05/16/2017 10:20 AM, Doug Hellmann wrote:
>>>
 Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:

> On Tue, 16 May 2017, Monty Taylor wrote:
>
> 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"?
>>
>
> "api key" is a fairly common and generic term for "this magical
> thingie I can create to delegate my authority to some automation".
> It's also sometimes called "token", perhaps that's better (that's
> what GitHub uses, for example)? In either case the "api" bit is
> pretty important because it is the thing used to talk to the API.
>
> I really hope we can avoid creating yet more special language for
> OpenStack. We've got an API. We want to send keys or tokens. Let's
> just call them that.
>
>
 +1

>>>
>>> Fair. That's an excellent argument for "api key" - because I certainly
>>> don't think we want to overload 'token'.
>>>
>>
>> As someone who accidentally named "API Microversions", I fully cede
>> naming territory to others here.
>>
>
> I named "jeepyb" on _purpose_.
>
> For those playing at home, that's a phoneticization of "GPB" which is an
> otherwise never-used acronym for "Gerrit Project Builder".
>
> /me hides
>
> It seems like there is general agreement on the review that "api key" is a
bad name. Thoughts on renaming it "application key" / "app key" (what Ron
proposed in an earlier version of this spec)?

Colleen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Zane Bitter]

On 18/05/17 09:23, Monty Taylor wrote:


But think of the following use cases:

As a user, I want to make an API key that I'm going to use for general
automation just like I use my Password auth plugin based user account
today. I want it to be able to do everything I can do today - but I
value the revocation features.

As a user, I want to make an API key that can only upload content to
swift. I don't want to have to list every possible other API call.


What if we think about it like this:

For step one:

- A User creates an API Key in a Project. It will be a blacklist Key.
- That API Key is created with identical role assignments to the User
that created it.
- The role assignment clone is done by keystone and is not tied to the
User's ability to perform role assignments
- All API Keys are hardcoded in keystone to not be able to do
(POST,DELETE) /projects/{project_id}/api-key
- All API Keys are hardcoded in keystone to not be able to do
(POST,PATCH,DELETE) /users
- All API Keys are hardcoded in keystone to not be able to do
(POST,PATCH,DELETE) /projects/{project_id}

For step two:
- A User creates a whitelist API Key. It can't do ANYTHING by default,
no further action is needed on API key restrictions.
- A User creates a blacklist API Key. All API Key restrictions from step
one are added as initial blacklist filters.

The change in step two would allow a User to decide that they want to
opt-in to letting an API Key do *dangerous* things - but it would
require explicit action on their part ... even if they have requested a
blacklist Key.

We should also potentially add a policy check that would disallow a User
from removing the API Key blacklist exclusions, since it's possible and
reasonable that an Admin does not want a User to be able to create keys
that can manage keys.


I'd encourage everyone to read this excellent blog post on how it works 
in AWS:


http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/

TL;DR: a policy document contains a Principal, an Action, a Resource and 
a Condition (like e.g. validity time). You can attach this policy 
_either_ to an IAM account (i.e. a User or Role - 'Role' being the 
equivalent of an auto-provisioned API key), in which case that account 
is assumed to be the Principal, _or_ to a resource (e.g. an S3 bucket), 
in which case that is assumed to be the Resource. AWS services 
themselves can also be Principals. IIUC access is default-deny and you 
open up individual stuff with a "Effect": "Allow" rule, but you can open 
up everything by setting  "Action": "*" and then blacklist stuff by 
adding "Effect": "Deny" rules.


When we're designing the initial API we need to keep in mind that the 
next stage will require a comparable level of sophistication to this.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Monty Taylor]

On 05/18/2017 04:32 PM, Zane Bitter wrote:

On 18/05/17 07:53, Sean Dague wrote:



My worry about policy also is that I'm not sure how safe it is for a
project owned API key to inherit permissions from the user who created
it. I can't think of a better way to it though but I'm still slightly
uncomfortable with it since a user with more roles could make a key
with  a subset of those which then someone else in the project can reset
the password for and then have access to a API key that 'may' be more
powerful than their own user. In clouds like ours where we allow
customers to create/manage users within the scope of their own projects,
there are often users who have different access all in the same project
and this could be an odd issue.

This is a super interesting point I hadn't considered, thanks for
bringing it up. We could probably address it by just blocking certain
operations entirely for APIKeys. I don't think we loose much in
preventing APIKeys from self reproducing. Blocking user/pw reset seems
like another good safety measure (it also just wouldn't work in
something like LDAP, because there is no write authority). That would be
a very good set of things to consider on Monty's spec of any APIs that
we're going to explicitly prohibit for APIKeys in iteration 1.


I can't actually think of a use case for even allowing 'password' (i.e.
key) changes/resets. If a user wants to replace one, we should make them
create a new API key, roll it out to their application, and then delete
the old one. (Bonus: Heat automates this workflow for you ;)


Totally agree.

I believe I have included all of these things in the latest rev of the 
spec - but I also possibly have not.



In the future when we have separate reader/writer roles in the default
policy then you'll definitely require the writer role to delete an API
key from the project (as you would for any other resource), so there'd
be no issue AFAICT.

cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Zane Bitter]

On 18/05/17 07:53, Sean Dague wrote:



My worry about policy also is that I'm not sure how safe it is for a
project owned API key to inherit permissions from the user who created
it. I can't think of a better way to it though but I'm still slightly
uncomfortable with it since a user with more roles could make a key
with  a subset of those which then someone else in the project can reset
the password for and then have access to a API key that 'may' be more
powerful than their own user. In clouds like ours where we allow
customers to create/manage users within the scope of their own projects,
there are often users who have different access all in the same project
and this could be an odd issue.

This is a super interesting point I hadn't considered, thanks for
bringing it up. We could probably address it by just blocking certain
operations entirely for APIKeys. I don't think we loose much in
preventing APIKeys from self reproducing. Blocking user/pw reset seems
like another good safety measure (it also just wouldn't work in
something like LDAP, because there is no write authority). That would be
a very good set of things to consider on Monty's spec of any APIs that
we're going to explicitly prohibit for APIKeys in iteration 1.


I can't actually think of a use case for even allowing 'password' (i.e. 
key) changes/resets. If a user wants to replace one, we should make them 
create a new API key, roll it out to their application, and then delete 
the old one. (Bonus: Heat automates this workflow for you ;)


In the future when we have separate reader/writer roles in the default 
policy then you'll definitely require the writer role to delete an API 
key from the project (as you would for any other resource), so there'd 
be no issue AFAICT.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Lance Bragstad]

I followed up with Sean in IRC [0]. My last note about rebuilding role
assignment dynamically doesn't really make sense. I was approaching this
from a different perspective.


[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-05-18.log.html#t2017-05-18T15:20:32

On Thu, May 18, 2017 at 9:39 AM, Lance Bragstad  wrote:

>
>
> On Thu, May 18, 2017 at 8:45 AM, Sean Dague  wrote:
>
>> On 05/18/2017 09:27 AM, Doug Hellmann wrote:
>> > Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:
>> >
>> >> Fully agree that expecting users of a particular cloud to understand
>> how
>> >> the policy stuff works is pointless, but it does fall on the cloud
>> >> provider to educate and document their roles and the permissions of
>> >> those roles. I think step 1 plus some basic role permissions for the
>> >
>> > Doesn't basing the API key permissions directly on roles also imply that
>> > the cloud provider has to anticipate all of the possible ways API keys
>> > might be used so they can then set up those roles?
>>
>> Not really. It's not explicit roles, it's inherited ones. At some point
>> an adminstrator gave a user permission to do stuff (through roles that
>> may be site specific). Don't care how we got there. The important thing
>> is those are cloned to the APIKey, otherwise, the APIKey litterally
>> would not be able to do anything, ever. Discussing roles here was an
>> attempt to look at how internals would work today, though it's
>> definitely not part of contract of this new interface.
>>
>> There is a lot more implicitness in what roles mean (see
>> https://bugs.launchpad.net/keystone/+bug/968696) which is another reason
>> I'm really skeptical that we should have roles or policy points in the
>> APIKey interface. Describing what they do in any particular installation
>> is a ton of work. And you thought ordering a Medium coffee at Starbucks
>> was annoying. :)
>>
>> The important thing is to make a clear and expressive API with the user
>> so they can be really clear about what they expect a thing should do.
>>
>> >> Keys with the expectation of operators to document their roles/policy
>> is
>> >> a safe enough place to start, and for us to document and set some
>> >> sensible default roles and policy. I don't think we currently have good
>> >
>> > This seems like an area where we want to encourage interoperability.
>> > Policy doesn't do that today, because deployers can use arbitrary
>> > names for roles and set permissions in those roles in any way they
>> > want. That's fine for human users, but doesn't work for enabling
>> > automation. If the sets of roles and permissions are different in
>> > every cloud, how would anyone write a key allocation script that
>> > could provision a key for their application on more than one cloud?
>>
>> So, this is where there are internals happening distinctly from user
>> expressed intent.
>>
>> POST /apikey {}
>>
>> Creates an APIKey, in the project the token is currently authed to, and
>> the APIKey inherits all the roles on that project that the user
>> currently has. The user may or may not even know what these are. It's
>> not a user interface.
>>
>
> If we know the user_id and project_id of the API key, then can't we build
> the roles dynamically whenever the API key is used (unless the API key is
> scoped to a single role)? This is the same approach we recently took with
> token validation because it made the revocation API sub-system *way*
> simpler (i.e. we no longer have to write revocation events anytime a role
> is removed from a user on a project, instead the revocation happens
> naturally when the token is used). Would this be helpful from a "default
> open" PoV with API keys?
>
> We touched on blacklisting certain operations a bit in Atlanta at the PTG
> (see the API key section) [0]. I attempted to document it shortly after the
> PTG, but some of those statement might be superseded at this point.
>
>
> [0] https://www.lbragstad.com/blog/keystone-pike-ptg-summary
>
>
>>
>> The contract is "Give me an APIKey that can do what I do*" (* with the
>> exception of self propogating, i.e. the skynet exception).
>>
>> That's iteration #1. APIKey can do what I can do.
>>
>> Iteration #2 is fine grained permissions that make it so I can have an
>> APIKey do far less than I can do.
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Lance Bragstad]

On Thu, May 18, 2017 at 8:45 AM, Sean Dague  wrote:

> On 05/18/2017 09:27 AM, Doug Hellmann wrote:
> > Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:
> >
> >> Fully agree that expecting users of a particular cloud to understand how
> >> the policy stuff works is pointless, but it does fall on the cloud
> >> provider to educate and document their roles and the permissions of
> >> those roles. I think step 1 plus some basic role permissions for the
> >
> > Doesn't basing the API key permissions directly on roles also imply that
> > the cloud provider has to anticipate all of the possible ways API keys
> > might be used so they can then set up those roles?
>
> Not really. It's not explicit roles, it's inherited ones. At some point
> an adminstrator gave a user permission to do stuff (through roles that
> may be site specific). Don't care how we got there. The important thing
> is those are cloned to the APIKey, otherwise, the APIKey litterally
> would not be able to do anything, ever. Discussing roles here was an
> attempt to look at how internals would work today, though it's
> definitely not part of contract of this new interface.
>
> There is a lot more implicitness in what roles mean (see
> https://bugs.launchpad.net/keystone/+bug/968696) which is another reason
> I'm really skeptical that we should have roles or policy points in the
> APIKey interface. Describing what they do in any particular installation
> is a ton of work. And you thought ordering a Medium coffee at Starbucks
> was annoying. :)
>
> The important thing is to make a clear and expressive API with the user
> so they can be really clear about what they expect a thing should do.
>
> >> Keys with the expectation of operators to document their roles/policy is
> >> a safe enough place to start, and for us to document and set some
> >> sensible default roles and policy. I don't think we currently have good
> >
> > This seems like an area where we want to encourage interoperability.
> > Policy doesn't do that today, because deployers can use arbitrary
> > names for roles and set permissions in those roles in any way they
> > want. That's fine for human users, but doesn't work for enabling
> > automation. If the sets of roles and permissions are different in
> > every cloud, how would anyone write a key allocation script that
> > could provision a key for their application on more than one cloud?
>
> So, this is where there are internals happening distinctly from user
> expressed intent.
>
> POST /apikey {}
>
> Creates an APIKey, in the project the token is currently authed to, and
> the APIKey inherits all the roles on that project that the user
> currently has. The user may or may not even know what these are. It's
> not a user interface.
>

If we know the user_id and project_id of the API key, then can't we build
the roles dynamically whenever the API key is used (unless the API key is
scoped to a single role)? This is the same approach we recently took with
token validation because it made the revocation API sub-system *way*
simpler (i.e. we no longer have to write revocation events anytime a role
is removed from a user on a project, instead the revocation happens
naturally when the token is used). Would this be helpful from a "default
open" PoV with API keys?

We touched on blacklisting certain operations a bit in Atlanta at the PTG
(see the API key section) [0]. I attempted to document it shortly after the
PTG, but some of those statement might be superseded at this point.


[0] https://www.lbragstad.com/blog/keystone-pike-ptg-summary


>
> The contract is "Give me an APIKey that can do what I do*" (* with the
> exception of self propogating, i.e. the skynet exception).
>
> That's iteration #1. APIKey can do what I can do.
>
> Iteration #2 is fine grained permissions that make it so I can have an
> APIKey do far less than I can do.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Sean Dague]

On 05/18/2017 09:27 AM, Doug Hellmann wrote:
> Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:
> 
>> Fully agree that expecting users of a particular cloud to understand how
>> the policy stuff works is pointless, but it does fall on the cloud
>> provider to educate and document their roles and the permissions of
>> those roles. I think step 1 plus some basic role permissions for the
> 
> Doesn't basing the API key permissions directly on roles also imply that
> the cloud provider has to anticipate all of the possible ways API keys
> might be used so they can then set up those roles?

Not really. It's not explicit roles, it's inherited ones. At some point
an adminstrator gave a user permission to do stuff (through roles that
may be site specific). Don't care how we got there. The important thing
is those are cloned to the APIKey, otherwise, the APIKey litterally
would not be able to do anything, ever. Discussing roles here was an
attempt to look at how internals would work today, though it's
definitely not part of contract of this new interface.

There is a lot more implicitness in what roles mean (see
https://bugs.launchpad.net/keystone/+bug/968696) which is another reason
I'm really skeptical that we should have roles or policy points in the
APIKey interface. Describing what they do in any particular installation
is a ton of work. And you thought ordering a Medium coffee at Starbucks
was annoying. :)

The important thing is to make a clear and expressive API with the user
so they can be really clear about what they expect a thing should do.

>> Keys with the expectation of operators to document their roles/policy is
>> a safe enough place to start, and for us to document and set some
>> sensible default roles and policy. I don't think we currently have good
> 
> This seems like an area where we want to encourage interoperability.
> Policy doesn't do that today, because deployers can use arbitrary
> names for roles and set permissions in those roles in any way they
> want. That's fine for human users, but doesn't work for enabling
> automation. If the sets of roles and permissions are different in
> every cloud, how would anyone write a key allocation script that
> could provision a key for their application on more than one cloud?

So, this is where there are internals happening distinctly from user
expressed intent.

POST /apikey {}

Creates an APIKey, in the project the token is currently authed to, and
the APIKey inherits all the roles on that project that the user
currently has. The user may or may not even know what these are. It's
not a user interface.

The contract is "Give me an APIKey that can do what I do*" (* with the
exception of self propogating, i.e. the skynet exception).

That's iteration #1. APIKey can do what I can do.

Iteration #2 is fine grained permissions that make it so I can have an
APIKey do far less than I can do.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Doug Hellmann]

Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200:

> Fully agree that expecting users of a particular cloud to understand how
> the policy stuff works is pointless, but it does fall on the cloud
> provider to educate and document their roles and the permissions of
> those roles. I think step 1 plus some basic role permissions for the

Doesn't basing the API key permissions directly on roles also imply that
the cloud provider has to anticipate all of the possible ways API keys
might be used so they can then set up those roles?

> Keys with the expectation of operators to document their roles/policy is
> a safe enough place to start, and for us to document and set some
> sensible default roles and policy. I don't think we currently have good

This seems like an area where we want to encourage interoperability.
Policy doesn't do that today, because deployers can use arbitrary
names for roles and set permissions in those roles in any way they
want. That's fine for human users, but doesn't work for enabling
automation. If the sets of roles and permissions are different in
every cloud, how would anyone write a key allocation script that
could provision a key for their application on more than one cloud?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Monty Taylor]

On 05/18/2017 06:53 AM, Sean Dague wrote:

On 05/17/2017 09:34 PM, Adrian Turjak wrote:



On 17/05/17 23:20, Sean Dague wrote:

On 05/16/2017 07:34 PM, Adrian Turjak wrote:


Anyway that aside, I'm sold on API keys as a concept in this case
provided they are project owned rather than user owned, I just don't
think we should make them too unique, and we shouldn't be giving them a
unique policy system because that way madness lies.

Policy is already a complicated system, lets not have to maintain two
systems. Any policy system we make for API keys ought to be built on top
of the policy systems we end up with using roles. An explosion of roles
will happen with dynamic policy anyway, and yes sadly it will be a DSL
for some clouds, but no sensible cloud operator is going to allow a
separate policy system in for API keys unless they can control it. I
don't think we can solve the "all clouds have the same policy for API
keys" problem and I'd suggest putting that in the "too hard for now
box". Thus we do your step 1, and leave step 2 until later when we have
a better idea of how to do it without pissing off a lot of operators,
breaking standard policy, or maintaining an entirely separate policy system.

This is definitely steps. And I agree we do step 1 to get us at least
revokable keys. That's Pike (hopefully), and then figure out the path
through step 2.

The thing about the policy system today, is it's designed for operators.
Honestly, the only way you really know what policy is really doing is if
you read the source code of openstack as well. That is very very far
from a declarative way of a user to further drop privileges. If we went
straight forward from here we're increasing the audience for this by a
factor of 1000+, with documentation, guarantees that policy points don't
ever change. No one has been thinking about microversioning on a policy
front, for instance. It now becomes part of a much stricter contract,
with a much wider audience.

I think the user experience of API use is going to be really bad if we
have to teach the world about our policy names. They are non mnemonic
for people familiar with the API. Even just in building up testing in
the Nova tree over the years mistakes have been made because it wasn't
super clear what routes the policies in question were modifying. Nova
did a giant replacement of all the policy names 2 cycles ago because of
that. It's better now, but still not what I'd want to thrust on people
that don't have at least 20% of the Nova source tree in their head.

We also need to realize there are going to be 2 levels of permissions
here. There is going to be what the operator allows (which is policy +
roles they have built up on there side), and then what the user allows
in their API Key. I would imagine that an API Key created by a user
inherits any roles that user has (the API Key is still owned by a
project). The user at any time can change the allowed routes on the key.
The admin at any time can change the role / policy structure. *both*
have to be checked on operations, and only if both succeed do we move
forward.

I think another question where we're clearly in a different space, is if
we think about granting an API Key user the ability to create a server.
In a classical role/policy move, that would require not just (compute,
"os_compute_api:servers:create"), but also (image, "get_image"), (image,
"download_image"), (network, "get_port"), (network, "create_port"), and
possibly much more. Missing one of these policies means a deep late
fail, which is not debugable unless you have the source code in front of
you. And not only requires knowledge of the OpenStack API, but deep
knowledge of the particular deployment, because the permissions needed
around networking might be different on different clouds.

Clearly, that's not the right experience for someone that just wants to
write a cloud native application that works on multiple clouds.

So we definitely are already doing something a bit different, that is
going to need to not be evaluated everywhere that policy is current
evaluated, but only *on the initial inbound request*. The user would
express this as (region1, compute, /servers, POST), which means that's
the API call they want this API Key to be able to make. Subsequent
requests wrapped in service tokens bypass checking API Key permissions.
The role system is still in play, keeping the API Key in the box the
operator wanted to put it in.

Given that these systems are going to act differently, and at different
times, I don't actually see it being a path to madness. I actually see
it as less confusing to manage correctly in the code, because they two
things won't get confused, and the wrong permissions checks get made. I
totally agree that policy today is far too complicated, and I fear
making it a new related, but very different task, way more than building
a different declarative approach that is easier for users to get right.

But... that being said, all of this p

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Sean Dague]

On 05/17/2017 09:34 PM, Adrian Turjak wrote:
> 
> 
> On 17/05/17 23:20, Sean Dague wrote:
>> On 05/16/2017 07:34 PM, Adrian Turjak wrote:
>> 
>>> Anyway that aside, I'm sold on API keys as a concept in this case
>>> provided they are project owned rather than user owned, I just don't
>>> think we should make them too unique, and we shouldn't be giving them a
>>> unique policy system because that way madness lies.
>>>
>>> Policy is already a complicated system, lets not have to maintain two
>>> systems. Any policy system we make for API keys ought to be built on top
>>> of the policy systems we end up with using roles. An explosion of roles
>>> will happen with dynamic policy anyway, and yes sadly it will be a DSL
>>> for some clouds, but no sensible cloud operator is going to allow a
>>> separate policy system in for API keys unless they can control it. I
>>> don't think we can solve the "all clouds have the same policy for API
>>> keys" problem and I'd suggest putting that in the "too hard for now
>>> box". Thus we do your step 1, and leave step 2 until later when we have
>>> a better idea of how to do it without pissing off a lot of operators,
>>> breaking standard policy, or maintaining an entirely separate policy system.
>> This is definitely steps. And I agree we do step 1 to get us at least
>> revokable keys. That's Pike (hopefully), and then figure out the path
>> through step 2.
>>
>> The thing about the policy system today, is it's designed for operators.
>> Honestly, the only way you really know what policy is really doing is if
>> you read the source code of openstack as well. That is very very far
>> from a declarative way of a user to further drop privileges. If we went
>> straight forward from here we're increasing the audience for this by a
>> factor of 1000+, with documentation, guarantees that policy points don't
>> ever change. No one has been thinking about microversioning on a policy
>> front, for instance. It now becomes part of a much stricter contract,
>> with a much wider audience.
>>
>> I think the user experience of API use is going to be really bad if we
>> have to teach the world about our policy names. They are non mnemonic
>> for people familiar with the API. Even just in building up testing in
>> the Nova tree over the years mistakes have been made because it wasn't
>> super clear what routes the policies in question were modifying. Nova
>> did a giant replacement of all the policy names 2 cycles ago because of
>> that. It's better now, but still not what I'd want to thrust on people
>> that don't have at least 20% of the Nova source tree in their head.
>>
>> We also need to realize there are going to be 2 levels of permissions
>> here. There is going to be what the operator allows (which is policy +
>> roles they have built up on there side), and then what the user allows
>> in their API Key. I would imagine that an API Key created by a user
>> inherits any roles that user has (the API Key is still owned by a
>> project). The user at any time can change the allowed routes on the key.
>> The admin at any time can change the role / policy structure. *both*
>> have to be checked on operations, and only if both succeed do we move
>> forward.
>>
>> I think another question where we're clearly in a different space, is if
>> we think about granting an API Key user the ability to create a server.
>> In a classical role/policy move, that would require not just (compute,
>> "os_compute_api:servers:create"), but also (image, "get_image"), (image,
>> "download_image"), (network, "get_port"), (network, "create_port"), and
>> possibly much more. Missing one of these policies means a deep late
>> fail, which is not debugable unless you have the source code in front of
>> you. And not only requires knowledge of the OpenStack API, but deep
>> knowledge of the particular deployment, because the permissions needed
>> around networking might be different on different clouds.
>>
>> Clearly, that's not the right experience for someone that just wants to
>> write a cloud native application that works on multiple clouds.
>>
>> So we definitely are already doing something a bit different, that is
>> going to need to not be evaluated everywhere that policy is current
>> evaluated, but only *on the initial inbound request*. The user would
>> express this as (region1, compute, /servers, POST), which means that's
>> the API call they want this API Key to be able to make. Subsequent
>> requests wrapped in service tokens bypass checking API Key permissions.
>> The role system is still in play, keeping the API Key in the box the
>> operator wanted to put it in.
>>
>> Given that these systems are going to act differently, and at different
>> times, I don't actually see it being a path to madness. I actually see
>> it as less confusing to manage correctly in the code, because they two
>> things won't get confused, and the wrong permissions checks get made. I
>> totally agree that policy today is far too comp

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Adrian Turjak]

On 17/05/17 23:20, Sean Dague wrote:
> On 05/16/2017 07:34 PM, Adrian Turjak wrote:
> 
>> Anyway that aside, I'm sold on API keys as a concept in this case
>> provided they are project owned rather than user owned, I just don't
>> think we should make them too unique, and we shouldn't be giving them a
>> unique policy system because that way madness lies.
>>
>> Policy is already a complicated system, lets not have to maintain two
>> systems. Any policy system we make for API keys ought to be built on top
>> of the policy systems we end up with using roles. An explosion of roles
>> will happen with dynamic policy anyway, and yes sadly it will be a DSL
>> for some clouds, but no sensible cloud operator is going to allow a
>> separate policy system in for API keys unless they can control it. I
>> don't think we can solve the "all clouds have the same policy for API
>> keys" problem and I'd suggest putting that in the "too hard for now
>> box". Thus we do your step 1, and leave step 2 until later when we have
>> a better idea of how to do it without pissing off a lot of operators,
>> breaking standard policy, or maintaining an entirely separate policy system.
> This is definitely steps. And I agree we do step 1 to get us at least
> revokable keys. That's Pike (hopefully), and then figure out the path
> through step 2.
>
> The thing about the policy system today, is it's designed for operators.
> Honestly, the only way you really know what policy is really doing is if
> you read the source code of openstack as well. That is very very far
> from a declarative way of a user to further drop privileges. If we went
> straight forward from here we're increasing the audience for this by a
> factor of 1000+, with documentation, guarantees that policy points don't
> ever change. No one has been thinking about microversioning on a policy
> front, for instance. It now becomes part of a much stricter contract,
> with a much wider audience.
>
> I think the user experience of API use is going to be really bad if we
> have to teach the world about our policy names. They are non mnemonic
> for people familiar with the API. Even just in building up testing in
> the Nova tree over the years mistakes have been made because it wasn't
> super clear what routes the policies in question were modifying. Nova
> did a giant replacement of all the policy names 2 cycles ago because of
> that. It's better now, but still not what I'd want to thrust on people
> that don't have at least 20% of the Nova source tree in their head.
>
> We also need to realize there are going to be 2 levels of permissions
> here. There is going to be what the operator allows (which is policy +
> roles they have built up on there side), and then what the user allows
> in their API Key. I would imagine that an API Key created by a user
> inherits any roles that user has (the API Key is still owned by a
> project). The user at any time can change the allowed routes on the key.
> The admin at any time can change the role / policy structure. *both*
> have to be checked on operations, and only if both succeed do we move
> forward.
>
> I think another question where we're clearly in a different space, is if
> we think about granting an API Key user the ability to create a server.
> In a classical role/policy move, that would require not just (compute,
> "os_compute_api:servers:create"), but also (image, "get_image"), (image,
> "download_image"), (network, "get_port"), (network, "create_port"), and
> possibly much more. Missing one of these policies means a deep late
> fail, which is not debugable unless you have the source code in front of
> you. And not only requires knowledge of the OpenStack API, but deep
> knowledge of the particular deployment, because the permissions needed
> around networking might be different on different clouds.
>
> Clearly, that's not the right experience for someone that just wants to
> write a cloud native application that works on multiple clouds.
>
> So we definitely are already doing something a bit different, that is
> going to need to not be evaluated everywhere that policy is current
> evaluated, but only *on the initial inbound request*. The user would
> express this as (region1, compute, /servers, POST), which means that's
> the API call they want this API Key to be able to make. Subsequent
> requests wrapped in service tokens bypass checking API Key permissions.
> The role system is still in play, keeping the API Key in the box the
> operator wanted to put it in.
>
> Given that these systems are going to act differently, and at different
> times, I don't actually see it being a path to madness. I actually see
> it as less confusing to manage correctly in the code, because they two
> things won't get confused, and the wrong permissions checks get made. I
> totally agree that policy today is far too complicated, and I fear
> making it a new related, but very different task, way more than building
> a different declarative approach 

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Sean Dague]

On 05/16/2017 08:08 PM, Zane Bitter wrote:
> On 16/05/17 01:06, Colleen Murphy wrote:
>> Additionally, I think OAuth - either extending the existing OAuth1.0
>> plugin or implementing OAuth2.0 - should probably be on the table.
> 
> I believe that OAuth is not a good fit for long-lived things like an
> application needing to communicate with its own infrastructure. Tokens
> are (a) tied to a user, and (b) expire, neither of which we want. Any
> use case where you can't just drop the user into a web browser and ask
> for their password at any time seem to be, at a minimum, excruciatingly
> painful and often impossible with OAuth, because that is the use case it
> was designed for.

I think that's the key bit I was noodling over when OAuth was brought
up. OAuth is really about acting as the user that created it. But one of
the very common concerns is how "when marry in IT quits, and she did all
the automated systems, what happens?" It's actually a quite common issue
(related issue) in the small organization space that the Twitter, shared
gmail, etc was set up by one staff member, who then leaves. And then
scramble hoping that they left an email address around. Because these
entities we less concerned about long term maintenance than initial sign up.

These things have to live at a project level to handle people
disappearing, and their access being revoked. You might want to rotate
keys then anyway on these things, depending.

I think that's one of the things about why OpenStack is going to be
different here. The shared project construct and resources belonging to
projects not users. I honestly wish more internet services understood
that as a common pattern. If there is a way that naturally fits in OAuth
that I'm not aware of cool. But if not, I think it comes off the table
pretty fast.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Sean Dague]

On 05/16/2017 07:34 PM, Adrian Turjak wrote:

> Anyway that aside, I'm sold on API keys as a concept in this case
> provided they are project owned rather than user owned, I just don't
> think we should make them too unique, and we shouldn't be giving them a
> unique policy system because that way madness lies.
> 
> Policy is already a complicated system, lets not have to maintain two
> systems. Any policy system we make for API keys ought to be built on top
> of the policy systems we end up with using roles. An explosion of roles
> will happen with dynamic policy anyway, and yes sadly it will be a DSL
> for some clouds, but no sensible cloud operator is going to allow a
> separate policy system in for API keys unless they can control it. I
> don't think we can solve the "all clouds have the same policy for API
> keys" problem and I'd suggest putting that in the "too hard for now
> box". Thus we do your step 1, and leave step 2 until later when we have
> a better idea of how to do it without pissing off a lot of operators,
> breaking standard policy, or maintaining an entirely separate policy system.

This is definitely steps. And I agree we do step 1 to get us at least
revokable keys. That's Pike (hopefully), and then figure out the path
through step 2.

The thing about the policy system today, is it's designed for operators.
Honestly, the only way you really know what policy is really doing is if
you read the source code of openstack as well. That is very very far
from a declarative way of a user to further drop privileges. If we went
straight forward from here we're increasing the audience for this by a
factor of 1000+, with documentation, guarantees that policy points don't
ever change. No one has been thinking about microversioning on a policy
front, for instance. It now becomes part of a much stricter contract,
with a much wider audience.

I think the user experience of API use is going to be really bad if we
have to teach the world about our policy names. They are non mnemonic
for people familiar with the API. Even just in building up testing in
the Nova tree over the years mistakes have been made because it wasn't
super clear what routes the policies in question were modifying. Nova
did a giant replacement of all the policy names 2 cycles ago because of
that. It's better now, but still not what I'd want to thrust on people
that don't have at least 20% of the Nova source tree in their head.

We also need to realize there are going to be 2 levels of permissions
here. There is going to be what the operator allows (which is policy +
roles they have built up on there side), and then what the user allows
in their API Key. I would imagine that an API Key created by a user
inherits any roles that user has (the API Key is still owned by a
project). The user at any time can change the allowed routes on the key.
The admin at any time can change the role / policy structure. *both*
have to be checked on operations, and only if both succeed do we move
forward.

I think another question where we're clearly in a different space, is if
we think about granting an API Key user the ability to create a server.
In a classical role/policy move, that would require not just (compute,
"os_compute_api:servers:create"), but also (image, "get_image"), (image,
"download_image"), (network, "get_port"), (network, "create_port"), and
possibly much more. Missing one of these policies means a deep late
fail, which is not debugable unless you have the source code in front of
you. And not only requires knowledge of the OpenStack API, but deep
knowledge of the particular deployment, because the permissions needed
around networking might be different on different clouds.

Clearly, that's not the right experience for someone that just wants to
write a cloud native application that works on multiple clouds.

So we definitely are already doing something a bit different, that is
going to need to not be evaluated everywhere that policy is current
evaluated, but only *on the initial inbound request*. The user would
express this as (region1, compute, /servers, POST), which means that's
the API call they want this API Key to be able to make. Subsequent
requests wrapped in service tokens bypass checking API Key permissions.
The role system is still in play, keeping the API Key in the box the
operator wanted to put it in.

Given that these systems are going to act differently, and at different
times, I don't actually see it being a path to madness. I actually see
it as less confusing to manage correctly in the code, because they two
things won't get confused, and the wrong permissions checks get made. I
totally agree that policy today is far too complicated, and I fear
making it a new related, but very different task, way more than building
a different declarative approach that is easier for users to get right.

But... that being said, all of this part is Queens. And regardless of
how this part falls out, the Pike work to just provision these API

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Zane Bitter]

On 16/05/17 01:06, Colleen Murphy wrote:

Additionally, I think OAuth - either extending the existing OAuth1.0
plugin or implementing OAuth2.0 - should probably be on the table.


I believe that OAuth is not a good fit for long-lived things like an 
application needing to communicate with its own infrastructure. Tokens 
are (a) tied to a user, and (b) expire, neither of which we want. Any 
use case where you can't just drop the user into a web browser and ask 
for their password at any time seem to be, at a minimum, excruciatingly 
painful and often impossible with OAuth, because that is the use case it 
was designed for.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Zane Bitter]

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 mailto:mord...@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 

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Adrian Turjak]

On 16/05/17 22:39, Sean Dague wrote:
> On 05/15/2017 10:00 PM, Adrian Turjak wrote:

>> 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.
>
>
>   -Sean
>
Thank you Sean! That is the answer I was after. I wanted a concrete
reason as to why we couldn't solve this in Keystone with users.

Whoever is working on the specs, please add something close to (emphasis
on the LDAP/AD/etc part):
"Users as a alternative isn't always viable because of the
inconsistencies in Keystone backends (LDAP/AD) and the (in)ability for
non-admin users to create additional users across different cloud
deployments and manage the roles of those created users."

I `may` have a possible solution to that problem... but it involves a
service external to Keystone to do non-admin user management, more on
that next week as I'll hopefully be ready to start announcing stuff.

Anyway that aside, I'm sold on API keys as a concept in this case
provided they are project owned rather than user owned, I just don't
think we should make them too unique, and we shouldn't be giving them a
unique policy system because that way madness lies.

Policy is already a complicated system, lets not have to maintain two
systems. Any policy system we make for API keys ought to b

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Monty Taylor]

On 05/16/2017 02:44 PM, Sean Dague wrote:

On 05/16/2017 03:40 PM, Monty Taylor wrote:

On 05/16/2017 10:20 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:

On Tue, 16 May 2017, Monty Taylor wrote:


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


"api key" is a fairly common and generic term for "this magical
thingie I can create to delegate my authority to some automation".
It's also sometimes called "token", perhaps that's better (that's
what GitHub uses, for example)? In either case the "api" bit is
pretty important because it is the thing used to talk to the API.

I really hope we can avoid creating yet more special language for
OpenStack. We've got an API. We want to send keys or tokens. Let's
just call them that.



+1


Fair. That's an excellent argument for "api key" - because I certainly
don't think we want to overload 'token'.


As someone who accidentally named "API Microversions", I fully cede
naming territory to others here.


I named "jeepyb" on _purpose_.

For those playing at home, that's a phoneticization of "GPB" which is an 
otherwise never-used acronym for "Gerrit Project Builder".


/me hides


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Sean Dague]

On 05/16/2017 03:40 PM, Monty Taylor wrote:
> On 05/16/2017 10:20 AM, Doug Hellmann wrote:
>> Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:
>>> On Tue, 16 May 2017, Monty Taylor wrote:
>>>
 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"?
>>>
>>> "api key" is a fairly common and generic term for "this magical
>>> thingie I can create to delegate my authority to some automation".
>>> It's also sometimes called "token", perhaps that's better (that's
>>> what GitHub uses, for example)? In either case the "api" bit is
>>> pretty important because it is the thing used to talk to the API.
>>>
>>> I really hope we can avoid creating yet more special language for
>>> OpenStack. We've got an API. We want to send keys or tokens. Let's
>>> just call them that.
>>>
>>
>> +1
> 
> Fair. That's an excellent argument for "api key" - because I certainly
> don't think we want to overload 'token'.

As someone who accidentally named "API Microversions", I fully cede
naming territory to others here.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Monty Taylor]

On 05/16/2017 10:20 AM, Doug Hellmann wrote:

Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:

On Tue, 16 May 2017, Monty Taylor wrote:


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


"api key" is a fairly common and generic term for "this magical
thingie I can create to delegate my authority to some automation".
It's also sometimes called "token", perhaps that's better (that's
what GitHub uses, for example)? In either case the "api" bit is
pretty important because it is the thing used to talk to the API.

I really hope we can avoid creating yet more special language for
OpenStack. We've got an API. We want to send keys or tokens. Let's
just call them that.



+1


Fair. That's an excellent argument for "api key" - because I certainly 
don't think we want to overload 'token'.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Doug Hellmann]

Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:
> On Tue, 16 May 2017, Monty Taylor wrote:
> 
> > 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"?
> 
> "api key" is a fairly common and generic term for "this magical
> thingie I can create to delegate my authority to some automation".
> It's also sometimes called "token", perhaps that's better (that's
> what GitHub uses, for example)? In either case the "api" bit is
> pretty important because it is the thing used to talk to the API.
> 
> I really hope we can avoid creating yet more special language for
> OpenStack. We've got an API. We want to send keys or tokens. Let's
> just call them that.
> 

+1

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Lance Bragstad]

On Tue, May 16, 2017 at 8:54 AM, Monty Taylor  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
 mailto:adri...@catalyst.net.nz>> wrote:

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

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Chris Dent]

On Tue, 16 May 2017, Monty Taylor wrote:

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


"api key" is a fairly common and generic term for "this magical
thingie I can create to delegate my authority to some automation".
It's also sometimes called "token", perhaps that's better (that's
what GitHub uses, for example)? In either case the "api" bit is
pretty important because it is the thing used to talk to the API.

I really hope we can avoid creating yet more special language for
OpenStack. We've got an API. We want to send keys or tokens. Let's
just call them that.

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Monty Taylor]

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
mailto:adri...@catalyst.net.nz>> wrote:



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.

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Sean Dague]

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
>> mailto:adri...@catalyst.net.nz>> wrote:

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

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Sun, May 14, 2017 at 6:59 PM, Monty Taylor  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.
>
> I probably will not have the time to actually implement the code - but if
> the PWG can help us get resources allocated to this I'll be happy to help
> them.
>
If anyone's counting, here are the current open specs (that I've found)
that attempt to address, in slightly different ways, the slightly different
use cases for API keys (not including the open specs to overhaul policy):

 - https://review.openstack.org/#/c/186979 - Subset tokens
 - https://review.openstack.org/#/c/389870 - Adding user credentials and
delegating role assignments to credential types
 - https://review.openstack.org/#/c/396634 - Standalone trusts
 - https://review.openstack.org/#/c/440593 - API keys
 - https://review.openstack.org/#/c/450415 - Application keys

Additionally, I think OAuth - either extending the existing OAuth1.0 plugin
or implementing OAuth2.0 - should probably be on the table.

Colleen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Adrian Turjak]

On 16/05/17 16:13, Colleen Murphy wrote:
> On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak
> mailto:adri...@catalyst.net.nz>> wrote:
> 
>
>
> Tangentially related to this (because my reasons are different),
> on our cloud I'm actually working on something like this, but
> under the hood all I'm doing is creating a user with a generated
> password and enforcing a username convention. I ask them for a
> name and what roles they want for the user and I spit out:
> username: "service_user_for_web_app_1@"
> password: ""
>
>  
> On Tue, May 16, 2017 at 4:10 AM, Adrian
> Turjak mailto:adri...@catalyst.net.nz>> wrote:
>
>
> On 16/05/17 14:00, Adrian Turjak wrote:
>
>  
>
>> 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?
>>
>> From my look at the specs the only feature difference compared to
>> users is optional expiry of the API keys. Why make something
>> entirely different for just that one feature when, as David says
>> in his spec, there is debate if that feature is even a good idea.
>>
>> As an application developer, I don't see why I can't just create
>> a user and limit the roles. I feel as if this is better addressed
>> with documentation because it almost sounds like people are
>> asking for something that already exists, but just doesn't have
>> as nice an API as they would like. Another option, make a better
>> API in Keystone for user creation/management alongside the old
>> one? That's pretty much what we did, except we wrote a service to
>> act as a proxy/wrapper around Keystone for some customer actions.
> If expiry is the killer feature, why no just add it to users?
> Temporary user accounts could solve that, and probably be useful
> beyond the scope of just API keys.
>
>  
> It's not just expiry. I think your proposal is missing one of the
> major use cases: empowerment of non-admin users. A non-admin can't
> create new users themselves, they have to (as you've pointed out) ask
> an admin to do it for them. As an application developer, I want to be
> able to delegate a subset of my own roles to a programmatic entity
> without being dependent on some other human. One of the (numerous)
> specs proposed seeks to address that use
> case: https://review.openstack.org/#/c/396634
>
> Colleen
>

That still doesn't seem like justification enough to make an entirely
new auth type and 'user-lite' model. The problem is that you have to be
admin to create users, that shouldn't have to be the case. You should be
able to create users, but ONLY give them roles for your projects or your
project tree. Keystone doesn't do that, and there is no way with policy
to do that currently. Hell, we wrote a service just to do that on behalf
our customers since keystone didn't give us that that level of control,
and because we really didn't want them needing an admin to do it for them.

So the features we are after are:
- the ability as a non-admin to create user or user-like access objects.
- the ability to maybe expire those

This is still sounding like a feature to get around flaws in the current
system rather than fix those flaws. Are we saying it is easier and
better to introduce more models and complexity than fix the existing
system to make it useful? We only did it in an external service because
we had additional requirements that didn't fit fit into core keystone,
but then ended up with a nice place to do some wrapper logic around the
limited keystone user management.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak 
wrote:

>
>
> Tangentially related to this (because my reasons are different), on our
> cloud I'm actually working on something like this, but under the hood all
> I'm doing is creating a user with a generated password and enforcing a
> username convention. I ask them for a name and what roles they want for the
> user and I spit out:
> username: "service_user_for_web_app_1@"
> password: ""
>
>
On Tue, May 16, 2017 at 4:10 AM, Adrian Turjak 
 wrote:
>
>
> On 16/05/17 14:00, Adrian Turjak wrote:
>


> 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?
>
> From my look at the specs the only feature difference compared to users is
> optional expiry of the API keys. Why make something entirely different for
> just that one feature when, as David says in his spec, there is debate if
> that feature is even a good idea.
>
> As an application developer, I don't see why I can't just create a user
> and limit the roles. I feel as if this is better addressed with
> documentation because it almost sounds like people are asking for something
> that already exists, but just doesn't have as nice an API as they would
> like. Another option, make a better API in Keystone for user
> creation/management alongside the old one? That's pretty much what we did,
> except we wrote a service to act as a proxy/wrapper around Keystone for
> some customer actions.
>
> If expiry is the killer feature, why no just add it to users? Temporary
> user accounts could solve that, and probably be useful beyond the scope of
> just API keys.
>

It's not just expiry. I think your proposal is missing one of the major use
cases: empowerment of non-admin users. A non-admin can't create new users
themselves, they have to (as you've pointed out) ask an admin to do it for
them. As an application developer, I want to be able to delegate a subset
of my own roles to a programmatic entity without being dependent on some
other human. One of the (numerous) specs proposed seeks to address that use
case: https://review.openstack.org/#/c/396634

Colleen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Adrian Turjak]

On 16/05/17 14:00, Adrian Turjak wrote:
>
> On 16/05/17 13:29, Lance Bragstad wrote:
>>
>>
>> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
>> mailto:adri...@catalyst.net.nz>> wrote:
>>
>>
>> On 16/05/17 01:09, Lance Bragstad wrote:
>>>
>>>
>>> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor
>>> mailto:mord...@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.
>>
>>
>> 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 

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Adrian Turjak]

On 16/05/17 13:29, Lance Bragstad wrote:
>
>
> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
> mailto:adri...@catalyst.net.nz>> wrote:
>
>
> On 16/05/17 01:09, Lance Bragstad wrote:
>>
>>
>> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor
>> mailto:mord...@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.
>
>
> 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 

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Lance Bragstad]

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak 
wrote:

>
> On 16/05/17 01:09, Lance Bragstad wrote:
>
>
>
> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor 
> 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.
>
>
> 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/4603

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Adrian Turjak]

On 16/05/17 01:09, Lance Bragstad wrote:
>
>
> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor  > 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.


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


Tangentially related to this (because my reasons are different), on our
cloud I'm actually working on something like this, but under the hood
all I'm doing is creating a user with a generated password and enforcing
a username convention. I ask them for a name and what roles they want
for the user and I spit out:
username: "service_user_for_web_app_1@"
password: ""

l'lI always generate/regenerate that password for them, and once shown
to them once, they can't ever see it again since the plaintext secret is
never stored. Sure I can't stop them from logging into the dashboard
with that user or changing the password thems

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Lance Bragstad]

On Sun, May 14, 2017 at 11:59 AM, Monty Taylor  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/


>
> I probably will not have the time to actually implement the code - but if
> the PWG can help us get resources allocated to this I'll be happy to help
> them.
>
> [0] https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
>> 
>> [1] https://review.openstack.org/#/c/450415/
>> 
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

[Monty Taylor]

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.


I probably will not have the time to actually implement the code - but 
if the PWG can help us get resources allocated to this I'll be happy to 
help them.



[0] https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal

[1] https://review.openstack.org/#/c/450415/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev