settingsLogin | Registersettings

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

0 votes

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.

Thanks,

Lance

[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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 18, 2017 in openstack-dev by Lance_Bragstad (11,080 points)   2 3 6

33 Responses

0 votes

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
https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
[1] https://review.openstack.org/#/c/450415/
https://review.openstack.org/#/c/450415/


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 14, 2017 by Monty_Taylor (22,780 points)   2 5 8
0 votes

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

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

https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
[1] https://review.openstack.org/#/c/450415/
https://review.openstack.org/#/c/450415/



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 15, 2017 by Lance_Bragstad (11,080 points)   2 3 6
0 votes

On 16/05/17 01:09, Lance Bragstad wrote:

On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mordred@inaugust.com
mordred@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 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: "serviceuserforwebapp_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 themselves directly, but that's
impossible to avoid without being able to set a fine grained role that
this user can't access password changing stuff. Ultimately though the
user changing their password isn't a problem, and someone else can
always delete the user or regen a password.

The only reason I'm even working on this is because we currently only
allow emails as username on our cloud through our management service. We
did that to avoid unique name constraints in a single domain, and to
allow us easier ways to do password reset tokens and inviting others to
join your project and set their own user password. But... our customers
also need a way to create service users with set roles. By enforcing the
name@ convention I get around the username unique constraint
but let them give useful descriptive names to these users.

Also worth noting that we have some custom policy files to allow some
very limited fine grained access control with roles. All I really
want/need is better/dynamic policies and honestly users are all the API
keys I can ever see being needed.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by Adrian_Turjak (2,660 points)   4 7
0 votes

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak adriant@catalyst.net.nz
wrote:

On 16/05/17 01:09, Lance Bragstad wrote:

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

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: "serviceuserforwebapp_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 themselves directly, but that's impossible to
avoid without being able to set a fine grained role that this user can't
access password changing stuff. Ultimately though the user changing their
password isn't a problem, and someone else can always delete the user or
regen a password.

The only reason I'm even working on this is because we currently only
allow emails as username on our cloud through our management service. We
did that to avoid unique name constraints in a single domain, and to allow
us easier ways to do password reset tokens and inviting others to join your
project and set their own user password. But... our customers also need a
way to create service users with set roles. By enforcing the name@
convention I get around the username unique constraint but let them give
useful descriptive names to these users.

Also worth noting that we have some custom policy files to allow some very
limited fine grained access control with roles. All I really want/need is
better/dynamic policies and honestly users are all the API keys I can ever
see being needed.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by Lance_Bragstad (11,080 points)   2 3 6
0 votes

On 16/05/17 13:29, Lance Bragstad wrote:

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
<adriant@catalyst.net.nz adriant@catalyst.net.nz> wrote:

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

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by Adrian_Turjak (2,660 points)   4 7
0 votes

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

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

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by Adrian_Turjak (2,660 points)   4 7
0 votes

On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak adriant@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: "serviceuserforwebapp_1@"
password: ""

On Tue, May 16, 2017 at 4:10 AM, Adrian Turjak adriant@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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by colleen_at_gazlene.n (1,780 points)   2
0 votes

On 16/05/17 16:13, Colleen Murphy wrote:
On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak
<adriant@catalyst.net.nz adriant@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@<project_id>"

password: ""


On Tue, May 16, 2017 at 4:10 AM, Adrian
Turjak <adriant@catalyst.net.nz adriant@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by Adrian_Turjak (2,660 points)   4 7
0 votes

On Sun, May 14, 2017 at 6:59 PM, Monty Taylor mordred@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.

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

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by colleen_at_gazlene.n (1,780 points)   2
0 votes

On 05/15/2017 10:00 PM, Adrian Turjak wrote:

On 16/05/17 13:29, Lance Bragstad wrote:

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak
<adriant@catalyst.net.nz adriant@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.
  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

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 16, 2017 by Sean_Dague (66,200 points)   4 11 19
...