Open Stack

On Tue, Dec 10, 2013 at 08:12:17AM -0600, Dolph Mathews wrote:
> On Mon, Dec 9, 2013 at 9:08 PM, Adam Young <ayoung at redhat.com> 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.

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.

Steve