[openstack-dev] [all][keystone][product] api keys/application specific passwords
zbitter at redhat.com
Tue May 16 23:56:06 UTC 2017
On 15/05/17 20:07, Adrian Turjak wrote:
> On 16/05/17 01:09, Lance Bragstad wrote:
>> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mordred at inaugust.com
>> <mailto:mordred at inaugust.com>> wrote:
>> On 05/11/2017 02:32 PM, Lance Bragstad wrote:
>> Hey all,
>> One of the Baremetal/VM sessions at the summit focused on what
>> we need
>> to do to make OpenStack more consumable for application
>> developers .
>> 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 .
>> The problem is that with all the recent churn in the keystone
>> 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
>> development perspective. Let's use this thread to see if there
>> is anyway
>> we can better enable the community through API
>> passwords by seeing if anyone can contribute resources to this
>> 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 .
>>  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
This was my assumption to start with as well - create a separate domain
backed by a DB, allow all users (not just admins) to create 'user'
accounts in that domain and assign roles on the current project that
they themselves hold to those accounts. That combined with a sane
default policy (where not every role gives you total access to the
projects) gets you to a point where you have application accounts
associated with a project but with no permissions to do anything. From
there you can add in a standard way of allowing the (actual) user to
delegate additional permissions to the account that are not captured in
Note that *either* way you end up with two authorisation mechanisms:
policy.json for operators and something else that end users can control.
Both mechanisms _could_ rely on Keystone roles, but likely at the
cost of an explosion of proliferating roles.
TBH I don't care too much which way we do it as long as it gets done :)
One point that was made in the session was that various organisations
may have strict policies or compliance requirements around how 'users'
are authenticated, and that we can pre-emptively avoid a world of hurt
for some of them by creating a primitive that is named literally
anything but 'user'.
A User-based system could possibly get operator-deployed applications
(i.e. Trove/Sahara/Magnum) to where they'd need to be quicker - which is
a consideration because this is a blocker for Kuryr - but I think they'd
end up in the same place. (I'd be more confident if we had the
service-locked VMs feature in Nova.)
The bottom line seems to be that it's a trade-off between having
different authorisation primitives for operators and users, or an
explosion of Keystone roles.
 Adam's talk
offered one such mechanism. Everybody in this thread should probably
More information about the OpenStack-dev