<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 08/31/2016 07:56 AM, Michael Still
wrote:<br>
</div>
<blockquote
cite="mid:CAEd1pt6mrJ2X_EB--_e7QNhnCsk1Z8QoCWfNJ6ahxL7XN+DviQ@mail.gmail.com"
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/">https://review.openstack.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>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAEd1pt6mrJ2X_EB--_e7QNhnCsk1Z8QoCWfNJ6ahxL7XN+DviQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Michael</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 31, 2016 at 7:54 AM, Matt
Riedemann <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 8/30/2016 4:36 PM, Michael Still wrote:<br>
</span>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">
Sorry for being slow on this one, I've been pulled into
some internal<br>
things at work.<br>
<br>
So... Talking to Matt Riedemann just now, it seems like
we should<br>
continue to pass through the user authentication details
when we have<br>
them to the plugin. The problem is what to do in the
case where we do<br>
not (which is mostly going to be when the instance
itself makes a<br>
metadata request).<br>
<br>
I think what you're saying though is that the middleware
wont let any<br>
requests through if they have no auth details? Is that
correct?<br>
<br>
Michael<br>
<br>
<br>
<br>
<br>
On Fri, Aug 26, 2016 at 12:46 PM, Adam Young <<a
moz-do-not-send="true" href="mailto:ayoung@redhat.com"
target="_blank">ayoung@redhat.com</a><br>
</span>
<div>
<div class="h5">
<mailto:<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>>>
wrote:<br>
<br>
On 08/22/2016 11:11 AM, Rob Crittenden wrote:<br>
<br>
Adam Young wrote:<br>
<br>
On 08/15/2016 05:10 PM, Rob Crittenden
wrote:<br>
<br>
Review <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/317739/"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/317739/</a><br>
<<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/317739/"
rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/317739/</a>>
added a new<br>
dynamic<br>
metadata handler to nova. The basic
jist is that rather<br>
than serving<br>
metadata statically, it can be done
dyamically, so that<br>
certain values<br>
aren't provided until they are needed,
mostly for<br>
security purposes<br>
(like credentials to enroll in an AD
domain). The<br>
metadata is<br>
configured as URLs to a REST service.<br>
<br>
Very little is passed into the REST
call, mostly UUIDs<br>
of the<br>
instance, image, etc. to ensure a
stable API. What this<br>
means though<br>
is that the REST service may need to
make calls into<br>
nova or glance to<br>
get information, like looking up the
image metadata in<br>
glance.<br>
<br>
Currently the dynamic metadata handler
_can_ generate<br>
auth headers if<br>
an authenticated request is made to
it, but consider<br>
that a common use<br>
case is fetching metadata from within
an instance using<br>
something like:<br>
<br>
% curl<br>
<a moz-do-not-send="true"
href="http://169.254.169.254/openstack/2016-10-06/vendor_data2.json"
rel="noreferrer" target="_blank">http://169.254.169.254/opensta<wbr>ck/2016-10-06/vendor_data2.<wbr>json</a><br>
<<a moz-do-not-send="true"
href="http://169.254.169.254/openstack/2016-10-06/vendor_data2.json"
rel="noreferrer" target="_blank">http://169.254.169.254/openst<wbr>ack/2016-10-06/vendor_data2.<wbr>json</a>><br>
<br>
This will come into the nova metadata
service<br>
unauthenticated.<br>
<br>
So a few questions:<br>
<br>
1. Is it possible to configure paste
(I'm a relative<br>
newbie) both<br>
authenticated and unauthenticated
requests are accepted<br>
such that IF<br>
an authenticated request comes it,
those credentials can<br>
be used,<br>
otherwise fall back to something else?<br>
<br>
<br>
<br>
Only if they are on different URLs, I
think. Its auth_token<br>
middleware<br>
for all services but Keystone. Keystone,
the rles are<br>
similar, but the<br>
implementation is a little different.<br>
<br>
<br>
Ok. I'm fine with the unauthenticated path if
the service we can<br>
just create a separate service user for it.<br>
<br>
2. If an unauthenticated request comes
in, how best to<br>
obtain a token<br>
to use? Is it best to create a service
user for the REST<br>
services<br>
(perhaps several), use a shared user,
something else?<br>
<br>
<br>
<br>
No unauthenticated requests, please. If
the call is to<br>
Keystone, we<br>
could use the X509 Tokenless approach, but
if the call comes<br>
from the<br>
new server, you won't have a cert by the
time you need to<br>
make the call,<br>
will you?<br>
<br>
<br>
Not sure which cert you're referring too but
yeah, the metadata<br>
service is unauthenticated. The requests can
come in from the<br>
instance which has no credentials (via <a
moz-do-not-send="true"
href="http://169.254.169.254/" rel="noreferrer"
target="_blank">http://169.254.169.254/</a>).<br>
<br>
Shared service users are probably your
best bet. We can<br>
limit the roles<br>
that they get. What are these calls you
need to make?<br>
<br>
<br>
To glance for image metadata, Keystone for
project information<br>
and nova for instance information. The REST
call passes in<br>
various UUIDs for these so they need to be
dereferenced. There<br>
is no guarantee that these would be called in
all cases but it<br>
is a possibility.<br>
<br>
rob<br>
<br>
<br>
I guess if config_drive is True then
this isn't really a<br>
problem as<br>
the metadata will be there in the
instance already.<br>
<br>
thanks<br>
<br>
rob<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
<br>
<br>
OpenStack Development Mailing List
(not for usage questions)<br>
Unsubscribe:<br>
<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
</div>
</div>
<<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><span
class=""><br>
<<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe:<br>
</span>
<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a>
<<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><span
class=""><br>
<<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe:<br>
<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
</span>
<<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a>
<<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><span
class=""><br>
<br>
<br>
Sounded like you had this sorted. True?<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe:<br>
<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
</span>
<<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><span
class=""><br>
<<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><br>
<br>
<br>
<br>
<br>
--<br>
Rackspace Australia<br>
<br>
<br>
</span><span class="">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote>
<br>
I think in the case of the initial boot we want all of the
virt drivers to be passing the auth details to the external
vendor data provider at a minimum in case that's going to
block requests with no auth headers. Otherwise that means
when we release newton that only works for the libvirt
driver. That's being fixed for the other virt drivers here:<br>
<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/348066/"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/348066/</a><br>
<br>
If the instance itself can't get updated information from
the metadata service because it doesn't have the auth
details, and nova isn't making an authenticated request on
it's behalf with a service user, then I don't see that as
being any worse off than the config drive case where you get
the data on initial boot and it doesn't change. It's not
great, but it's not something we have to hold this up for as
we're 2 days away from feature freeze.<br>
<br>
So I think we should get <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/348066/"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/348066/</a>
merged for Newton and work on what to do about
unauthenticated requests from the instance as a future
enhancement.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">Rackspace
Australia</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>