Open Stack

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

Sounded like you had this sorted.  True?