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

Adam Young ayoung at redhat.com
Wed Aug 17 20:16:02 UTC 2016

On 08/15/2016 05:10 PM, Rob Crittenden wrote:
> Review 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
> 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.
> 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?

Shared service users are probably your best bet.  We can limit the roles 
that they get.  What are these calls you need to make?

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

More information about the OpenStack-dev mailing list