Open Stack

On 08/30/2016 05:36 PM, Michael Still wrote:
> Sorry for being slow on this one, I've been pulled into some internal 
> things at work.
>
> So... Talking to Matt Riedemann just now, it seems like we should 
> continue to pass through the user authentication details when we have 
> them to the plugin. The problem is what to do in the case where we do 
> not (which is mostly going to be when the instance itself makes a 
> metadata request).
>
> I think what you're saying though is that the middleware wont let any 
> requests through if they have no auth details? Is that correct?
>
Yes, that is correct.

> Michael
>
>
>
>
> On Fri, Aug 26, 2016 at 12:46 PM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 08/22/2016 11:11 AM, Rob Crittenden wrote:
>
>         Adam Young wrote:
>
>             On 08/15/2016 05:10 PM, Rob Crittenden wrote:
>
>                 Review https://review.openstack.org/#/c/317739/
>                 <https://review.openstack.org/#/c/317739/> added a new
>                 dynamic
>                 metadata handler to nova. The basic jist is that
>                 rather than serving
>                 metadata statically, it can be done dyamically, so
>                 that certain values
>                 aren't provided until they are needed, mostly for
>                 security purposes
>                 (like credentials to enroll in an AD domain). The
>                 metadata is
>                 configured as URLs to a REST service.
>
>                 Very little is passed into the REST call, mostly UUIDs
>                 of the
>                 instance, image, etc. to ensure a stable API. What
>                 this means though
>                 is that the REST service may need to make calls into
>                 nova or glance to
>                 get information, like looking up the image metadata in
>                 glance.
>
>                 Currently the dynamic metadata handler _can_ generate
>                 auth headers if
>                 an authenticated request is made to it, but consider
>                 that a common use
>                 case is fetching metadata from within an instance
>                 using something like:
>
>                 % curl
>                 http://169.254.169.254/openstack/2016-10-06/vendor_data2.json
>                 <http://169.254.169.254/openstack/2016-10-06/vendor_data2.json>
>
>                 This will come into the nova metadata service
>                 unauthenticated.
>
>                 So a few questions:
>
>                 1. Is it possible to configure paste (I'm a relative
>                 newbie) both
>                 authenticated and unauthenticated requests are
>                 accepted such that IF
>                 an authenticated request comes it, those credentials
>                 can be used,
>                 otherwise fall back to something else?
>
>
>
>             Only if they are on different URLs, I think.  Its
>             auth_token middleware
>             for all services but Keystone.  Keystone, the rles are
>             similar, but the
>             implementation is a little different.
>
>
>         Ok. I'm fine with the unauthenticated path if the service we
>         can just create a separate service user for it.
>
>                 2. If an unauthenticated request comes in, how best to
>                 obtain a token
>                 to use? Is it best to create a service user for the
>                 REST services
>                 (perhaps several), use a shared user, something else?
>
>
>
>             No unauthenticated requests, please.  If the call is to
>             Keystone, we
>             could use the X509 Tokenless approach, but if the call
>             comes from the
>             new server, you won't have a cert by the time you need to
>             make the call,
>             will you?
>
>
>         Not sure which cert you're referring too but yeah, the
>         metadata service is unauthenticated. The requests can come in
>         from the instance which has no credentials (via
>         http://169.254.169.254/).
>
>             Shared service users are probably your best bet.  We can
>             limit the roles
>             that they get.  What are these calls you need to make?
>
>
>         To glance for image metadata, Keystone for project information
>         and nova for instance information. The REST call passes in
>         various UUIDs for these so they need to be dereferenced. There
>         is no guarantee that these would be called in all cases but it
>         is a possibility.
>
>         rob
>
>
>                 I guess if config_drive is True then this isn't really
>                 a problem as
>                 the metadata will be there in the instance already.
>
>                 thanks
>
>                 rob
>
>                 __________________________________________________________________________
>
>
>                 OpenStack Development Mailing List (not for usage
>                 questions)
>                 Unsubscribe:
>                 OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>                 <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>                 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
>             __________________________________________________________________________
>
>             OpenStack Development Mailing List (not for usage questions)
>             Unsubscribe:
>             OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>         __________________________________________________________________________
>
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>     Sounded like you had this sorted.  True?
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> -- 
> Rackspace Australia
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160831/5359b1ff/attachment.html>