[openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

Yee, Guang guang.yee at hp.com
Tue Dec 10 02:53:15 UTC 2013


There's a HMAC-based generic signature authentication plugin patch which
should meet your needs.

https://review.openstack.org/#/c/40036/

Now the hard part, code review. :)


Guang


> -----Original Message-----
> From: Steven Hardy [mailto:shardy at redhat.com]
> Sent: Monday, December 09, 2013 2:34 PM
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and
> request signing
> 
> 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?
> 
> - Validating requests signed with ec2 credentials stored via
> v3/credentials
>   does not work, if you try to use v2.0/ec2tokens, should it?
> 
> 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.
> 
> 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?
> 
> 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!
> 
> Thanks!
> 
> Steve
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6183 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/c1430315/attachment.bin>


More information about the OpenStack-dev mailing list