[openstack-dev] [nova][keystone] auth for new metadata plugins

Adam Young ayoung at redhat.com
Thu Sep 1 01:58:15 UTC 2016


On 08/31/2016 07:56 AM, Michael Still wrote:
> 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.
>
So, I don't think we need it.  I think that doing an identity for the 
new node *in order* to register it with an IdP is backwards: register 
it, and use the identity from the IdP via Federation.

Anything authenticated should be done from the metadata server or from 
Nova itself, based on the token used to launch the workflow.


> Michael
>
> On Wed, Aug 31, 2016 at 7:54 AM, Matt Riedemann 
> <mriedem at linux.vnet.ibm.com <mailto: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>
>         <mailto: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/>
>                         <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>
>                        
>         <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://OpenStack-dev-request@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>
>                        
>         <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://OpenStack-dev-request@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>
>                    
>         <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://OpenStack-dev-request@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>
>         <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://OpenStack-dev-request@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>
>            
>         <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://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>
>
>
>     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/
>     <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/
>     <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://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/34ed14e4/attachment.html>


More information about the OpenStack-dev mailing list