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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
