On 09/01/2016 08:48 PM, Michael Still wrote:
On Thu, Sep 1, 2016 at 11:58 AM, Adam Young <ayo...@redhat.com
<mailto:ayo...@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-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
