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

Adam Young ayoung at redhat.com
Thu Sep 8 16:25:48 UTC 2016


On 09/01/2016 08:48 PM, Michael Still wrote:
> On Thu, Sep 1, 2016 at 11:58 AM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 08/31/2016 07:56 AM, Michael Still wrote:
>>     There is a quick sketch of what a service account might look like
>>     at https://review.openstack.org/#/c/363606/
>>     <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.
>>
>     So, I don't think we need it.  I think that doing an identity for
>     the new node *in order* to register it with an IdP is backwards: 
>     register it, and use the identity from the IdP via Federation.
>
>     Anything authenticated should be done from the metadata server or
>     from Nova itself, based on the token used to launch the workflow.
>
>
> I'm not sure we're on the same page here. The flows would be something 
> like this:
>
>  - Instance boot request
>    - Initiating user token is available, and is passed through to the 
> vendordata REST service
>    - Metadata _might_ be generated, if the instance is using config drive
>
>  - Metadata request from within the instance (any use case not using 
> config drive)
>   - No user token, this is just cloud-init running on the instance, 
> although it could be other client software too
>   - We don't have a token to pass to the vendordata REST service, so 
> we currently pass nothing, keystone middleware denies request
>
> So, its those post-boot requests from inside the instance that have me 
> concerned.

I gues I was not clear on wehat you were doping here.  Is this a service 
user for additional calls to the metadata service for post-boot only?  I 
would think that, by then,. the instance should have an identity, and 
that identity would be used for calls to the outside world.  But I gues 
this is from nova-metadata to vendordata dynamic?  I thought 
nova-metadata already had a service account?

The chain of identity is from the user requesting the new VM to Nova to 
the join service.  When the VM kicks off, all the vendordata dynamic 
join service cares about is the the instance is the expected instance, 
and then it will hand down whatever it needs.

Let's say that what we were doing here is provisioning a Keystone user 
for each instance (not suggesting, just showing) and assigning the user 
a role in the project that owns the VM.  All of that work would be done 
by the join service upon notification from Nova that there is a new VM.  
What would then go to the instance would be the new userid and the 
keystone credential (Password?) that the vm can use.  Yes, it would be 
good if the instance were then to change the password.

In general, the join service should run as a specific user, and 
operations performed are not necessarily those limited by the token of 
the user requesting the new VM.  Put another way, just because a user 
can create a VM and thus a host entry in the IdP does not mean that same 
user can directly create a host entry in the IdP.

A user should not be able to call the Join service directly, either.  It 
should only be call-able by Nova.



>
> Michael
>
>
>
> -- 
> Rackspace Australia
>
>
> __________________________________________________________________________
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/45afd2cc/attachment.html>


More information about the OpenStack-dev mailing list