openstack team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

Origianlly respoded just to Christopher.  Forwarding this on to a the 
main list.

First of all, let me say thanks to everyone participating in the 
discussion. This is the only way we are going to identify all of the 
issues and come up with a decent implementation. I knew this would be a 
touchy subject when we first started designing it, and suspected that it 
would take some form of commit before the discussion hit the majority of 
the community.


On 08/02/2012 02:20 PM, Christopher MacGown wrote:
> On Thursday, August 2, 2012 at 6:59 AM, Adam Young wrote:
> > So, let me put the onus on you:  make the argument for rapid 
> > revocation of tokens.
> If you are deploying OpenStack and providing access to third parties, 
> and for whatever reason you terminate a relationship with that third 
> party — whether they cancel, you've banned them, you've removed a user 
> from a tenant/project — you want that third party to immediately lose 
> access to whatever capability they had prior to that termination. 
> Leaving non-affiliated users with access to resources is a serious 
> security risk that would make OpenStack  unusable in a regulated 
> environment.

In those cases, you probably want to continue on with online token 
checking,  regardless of UUID/PKI.  That ability will not go away.  We 
probably do need a configuration option for auth_token that indicates 
whether it should verify with PKI or not,  but my guess is that the real 
policy will be dictated by keystone. Perhaps what we really need is for 
the remote services to query this value from the keystone server.  It 
could do the check when it origianally fetches certificates.  The 
certificates themselves could be shorter lived (say 24 hours) and 
refreshed when they expire.

Automatic Management of the certificates probably should also be 
configurable, with many organizations preferring to use Puppet etc.

I suspect that we are going to want a more nuanced policy/mechanism long 
term,  something along the lines of:

Tenant specific PKI tickets are short lived, say 5 minutes.
Non-tenant specific tickets are used to get tenant specific tickets.
Long running tasks will call back to Keystone to verify ticket validity 
using  UUID tokens.


If we start doing something along the lines of Federation as I've started
https://blueprints.launchpad.net/keystone/+spec/federation
You would also have the option of revoking the signing certificate for a 
whole domain,  which would be an effective way to deny access to a swath 
of people, say on a breach of contract.

In large organziations, there is always going to be some non-zero delay 
between the decision to  revocation authorization and the implementation 
of that decision.  With LDAP replication,  at a minimum you have the 
replication delay.  The question is what that acceptable delay is in a 
given scenario.  It may not be the same even for all use cases even in a 
large organization.



> --
> Christopher MacGown, CTO
> Piston Cloud Computing, Inc.
> w: (650) 24-CLOUD
> m: (415) 300-0944
> http://www.pistoncloud.com