Open Stack

There is a quick sketch of what a service account might look like at
https://review.openstack.org/#/c/363606/ -- I need to do some more fiddling
to get the new option group working, but I could do that if we wanted to
try and get this into Newton.

Michael

On Wed, Aug 31, 2016 at 7:54 AM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> On 8/30/2016 4: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?
>>
>> 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/openst
>> ack/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.op
>> enstack.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/cg
>> i-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/openstac
>> k-dev
>>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
>> ck-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:un
>> subscribe>
>>         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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> I think in the case of the initial boot we want all of the virt drivers to
> be passing the auth details to the external vendor data provider at a
> minimum in case that's going to block requests with no auth headers.
> Otherwise that means when we release newton that only works for the libvirt
> driver. That's being fixed for the other virt drivers here:
>
> https://review.openstack.org/#/c/348066/
>
> If the instance itself can't get updated information from the metadata
> service because it doesn't have the auth details, and nova isn't making an
> authenticated request on it's behalf with a service user, then I don't see
> that as being any worse off than the config drive case where you get the
> data on initial boot and it doesn't change. It's not great, but it's not
> something we have to hold this up for as we're 2 days away from feature
> freeze.
>
> So I think we should get https://review.openstack.org/#/c/348066/ merged
> for Newton and work on what to do about unauthenticated requests from the
> instance as a future enhancement.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __________________________________________________________________________
> 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
>



-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160831/083f342d/attachment.html>