<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 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 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><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>