On Tue, Dec 10, 2013 at 9:13 AM, Steven Hardy <[email protected]> wrote:
> On Tue, Dec 10, 2013 at 08:12:17AM -0600, Dolph Mathews wrote: > > On Mon, Dec 9, 2013 at 9:08 PM, Adam Young <[email protected]> wrote: > > > > > > > > > > > > > > On 12/09/2013 05:34 PM, Steven Hardy wrote: > > > > > >> Hi all, > > >> > > >> I have some queries about what the future of the ec2tokens API is for > > >> keystone, context as we're looking to move Heat from a horrible > mixture of > > >> v2/v3 keystone to just v3, currently I'm not sure we can: > > >> > > >> - The v3/credentials API allows ec2tokens to be stored (if you > > >> create the access/secret key yourself), but it requires admin, > which > > >> creating an ec2-keypair via the v2 API does not? > > >> > > >> - There is no v3 interface for validating signed requests like you > can via > > >> POST v2.0/ec2tokens AFAICT? > > >> > > > > > I thought both of these were "accidentally" introduced in v3 by including > > the ec2 middleware in the v3 pipeline by default back in grizzly? > > Essentially making them undocumented APIs. I haven't tested it myself. > > Oh, that is useful info, thanks! > > I've just tested and the signature validation does work via v3/ec2tokens > > > >> - Validating requests signed with ec2 credentials stored via > > >> v3/credentials > > >> does not work, if you try to use v2.0/ec2tokens, should it? > > >> > > > > > What's the blocker / what doesn't work? > > So there seem to be a couple of issues: > - There's a keystoneclient bug which prevents you from creating or updating > credentials via v3/credentials with a type of 'ec2', I've posted a patch: > > https://bugs.launchpad.net/python-keystoneclient/+bug/1259461 > > https://review.openstack.org/#/c/61046/ > > Then with that fixed, you get 500 if you try to validate a request signed > with an ec2 keypair stored via v3/credentials. Looks fixable, raised this > bug: > > https://bugs.launchpad.net/keystone/+bug/1259584 > > I'll look at a creating a fix for this. > > > >> So my question is basically, what's the future of ec2tokens, is there > some > > >> alternative in the pipeline for satisfying the same use-case? > > >> > > >> The main issues we have in Heat: > > >> > > >> - We want to continue supporting AWS style signed requests for our > > >> cloudformation-compatible API, which is currently done via > ec2tokens. > > >> > > >> - ec2 keypairs are currently the only method of getting a non-expiring > > >> credential which we can deploy in-instance, that is no longer > possible > > >> via the v3 API for the reasons above. > > >> > > > > > As mentioned below, access keys don't necessarily expire, and can be > > utilized without storing a user identity (you just need to store an OAuth > > access key & secret key). When generating OpenStack tokens, they > > impersonate they user who delegated authorization. > > Ok, thanks for the info. But there's currently no way to authenticate with > a service via these credentials right, we'd need some new middleware? > > > >> What is the recommended way for us to deploy a (non expiring) > credential > > >> in > > >> an instance (ideally derived from a trust or otherwise role-limited), > then > > >> use that credential to authenticate against our API? > > >> > > > > > > X509. > > > > > > The issue, as I understand it, is that there is no user object to back > > > that credential. You don't have a user to execute the trust. > > > > > > Note that you should not be deriving a credential from a trust, you > should > > > be linking a trust to a credential. > > > > > > The KDS code base has a similar problem. We need a longer term > credential > > > service for internal components of Open Stack. KDS is going to do it > with > > > symmetric keys, which might serve your needs. This is usually done via > > > Kerberos in enterprise deployments. > > > > > > > > >> My first thought is that the easiest solution would be to allow trust > > >> scoped tokens to optionally be configured to not expire (until we > delete > > >> the trust when we delete the Heat stack)? > > >> > > >> Can anyone offer any suggestions on a v3 compatible way to do this? > > >> > > >> I did start looking at oauth as a possible solution, but it seems the > > >> client support is not yet there, and there's no auth middleware we > can use > > >> for authenticating requests containing oauth credentials, any ideas > on the > > >> status of this would be most helpful! > > >> > > > > > The current implementation basically requires you to exchange an OAuth > > access token for an identity v3 token -- we don't have middleware to > > validate OAuth-signed requests like we do for identity API tokens > > (auth_token). > > Ok, so for our in-instance use-case that means we need the OAuth tokens and > keystone credentials to get an ordinary v3 token? Which for our use-case > defeats the purpose of having the OAuth key, so it's a non-starter. > No, there is no "keystone identity" whose credentials you would need to store. It's just OAuth access key + secret key. OAuth alone effectively becomes a means of authenticating with keystone. It's already scoped to a particular project with limited authorization, as well. I assume this affects your basis for asking the next few questions so I'm going to skip them... > > Based on the info you've provied, it sounds like we can probably get > ec2tokens auth working via v3, which is great, but we are *very* keen to > provide an "openstack native" alternative, for folks who don't want to use > the ec2 stuff. > > What about the idea of just making token expiry optional for trust scoped > tokens? Then we could just use existing auth_token middleware. Is that a > totally dumb idea? > I'm just thinking it would be really great (from a user-of-keystone > perspective) if we could avoid further fragmentation and just have one type > of shared secret (a keystone token), which can be configured flexibly > enough to satisfy the various use-cases? > > The alternative seems to be some new middleware which can authenticate > requests via $some_other_credential_possibly_oauth signed requests. > I'd like to have this bit anyway :) (to replace "openstack tokens" with some form of PKI-based OAuth that happens transparently for end users). > > Steve > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
