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