Open Stack

On Tue, Dec 10, 2013 at 9:13 AM, Steven Hardy <shardy at redhat.com> 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 <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.
>

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/b8aec7a6/attachment.html>