<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/01/2016 08:48 PM, Michael Still
wrote:<br>
</div>
<blockquote
cite="mid:CAEd1pt5QWfQPsy__pgJnvRsh=n5yMYsB8zcKakGF=U6R-BYxzQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Sep 1, 2016 at 11:58 AM, Adam
Young <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 08/31/2016 07:56 AM, Michael Still wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">There is a quick sketch of what a
service account might look like at <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/363606/"
target="_blank">https://review.openstack.<wbr>org/#/c/363606/</a>
-- 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.
<div><br>
</div>
</div>
</blockquote>
</span> 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.<br>
<br>
Anything authenticated should be done from the metadata
server or from Nova itself, based on the token used to
launch the workflow.</div>
</blockquote>
</div>
<div class="gmail_extra"><br>
</div>
I'm not sure we're on the same page here. The flows would be
something like this:</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"> - Instance boot request</div>
<div class="gmail_extra"> - Initiating user token is
available, and is passed through to the vendordata REST
service</div>
<div class="gmail_extra"> - Metadata _might_ be generated, if
the instance is using config drive<br clear="all">
<div><br>
</div>
<div> - Metadata request from within the instance (any use
case not using config drive)</div>
<div> - No user token, this is just cloud-init running on the
instance, although it could be other client software too</div>
<div> - We don't have a token to pass to the vendordata REST
service, so we currently pass nothing, keystone middleware
denies request</div>
<div><br>
</div>
<div>So, its those post-boot requests from inside the instance
that have me concerned.</div>
</div>
</div>
</blockquote>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
A user should not be able to call the Join service directly,
either. It should only be call-able by Nova.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAEd1pt5QWfQPsy__pgJnvRsh=n5yMYsB8zcKakGF=U6R-BYxzQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div><br>
</div>
<div>Michael</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">Rackspace
Australia</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>