[openstack-dev] [nova][keystone] auth for new metadata plugins
ayoung at redhat.com
Fri Aug 26 02:46:00 UTC 2016
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/ 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.
>>> I guess if config_drive is True then this isn't really a problem as
>>> the metadata will be there in the instance already.
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Sounded like you had this sorted. True?
More information about the OpenStack-dev