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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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: >> [email protected] >> 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: >> [email protected]?subject:unsubscribe >> <http://[email protected]?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: >> [email protected]?subject:unsubscribe >> <http://[email protected]?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: >> [email protected]?subject:unsubscribe >> <http://[email protected]?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: [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rackspace Australia
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
