Adam Young wrote:
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 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
