Open Stack

On 16/05/17 22:39, Sean Dague wrote:
> On 05/15/2017 10:00 PM, Adrian Turjak wrote:
<snip>
>> 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 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.