Michael
On Wed, Aug 31, 2016 at 7:54 AM, Matt Riedemann
<mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>> wrote:
On 8/30/2016 4:36 PM, Michael Still wrote:
Sorry for being slow on this one, I've been pulled into some
internal
things at work.
So... Talking to Matt Riedemann just now, it seems like we should
continue to pass through the user authentication details when
we have
them to the plugin. The problem is what to do in the case
where we do
not (which is mostly going to be when the instance itself makes a
metadata request).
I think what you're saying though is that the middleware wont
let any
requests through if they have no auth details? Is that correct?
Michael
On Fri, Aug 26, 2016 at 12:46 PM, Adam Young
<ayo...@redhat.com <mailto:ayo...@redhat.com>
<mailto:ayo...@redhat.com <mailto:ayo...@redhat.com>>> wrote:
On 08/22/2016 11:11 AM, Rob Crittenden wrote:
Adam Young wrote:
On 08/15/2016 05:10 PM, Rob Crittenden wrote:
Review
https://review.openstack.org/#/c/317739/
<https://review.openstack.org/#/c/317739/>
<https://review.openstack.org/#/c/317739/
<https://review.openstack.org/#/c/317739/>> added a new
dynamic
metadata handler to nova. The basic jist is
that rather
than serving
metadata statically, it can be done
dyamically, so that
certain values
aren't provided until they are needed, mostly for
security purposes
(like credentials to enroll in an AD domain). The
metadata is
configured as URLs to a REST service.
Very little is passed into the REST call,
mostly UUIDs
of the
instance, image, etc. to ensure a stable API.
What this
means though
is that the REST service may need to make
calls into
nova or glance to
get information, like looking up the image
metadata in
glance.
Currently the dynamic metadata handler _can_
generate
auth headers if
an authenticated request is made to it, but
consider
that a common use
case is fetching metadata from within an
instance using
something like:
% curl
http://169.254.169.254/openstack/2016-10-06/vendor_data2.json
<http://169.254.169.254/openstack/2016-10-06/vendor_data2.json>
<http://169.254.169.254/openstack/2016-10-06/vendor_data2.json
<http://169.254.169.254/openstack/2016-10-06/vendor_data2.json>>
This will come into the nova metadata service
unauthenticated.
So a few questions:
1. Is it possible to configure paste (I'm a
relative
newbie) both
authenticated and unauthenticated requests are
accepted
such that IF
an authenticated request comes it, those
credentials can
be used,
otherwise fall back to something else?
Only if they are on different URLs, I think. Its
auth_token
middleware
for all services but Keystone. Keystone, the rles are
similar, but the
implementation is a little different.
Ok. I'm fine with the unauthenticated path if the
service we can
just create a separate service user for it.
2. If an unauthenticated request comes in, how
best to
obtain a token
to use? Is it best to create a service user
for the REST
services
(perhaps several), use a shared user,
something else?
No unauthenticated requests, please. If the call
is to
Keystone, we
could use the X509 Tokenless approach, but if the
call comes
from the
new server, you won't have a cert by the time you
need to
make the call,
will you?
Not sure which cert you're referring too but yeah, the
metadata
service is unauthenticated. The requests can come in
from the
instance which has no credentials (via
http://169.254.169.254/).
Shared service users are probably your best bet.
We can
limit the roles
that they get. What are these calls you need to make?
To glance for image metadata, Keystone for project
information
and nova for instance information. The REST call passes in
various UUIDs for these so they need to be
dereferenced. There
is no guarantee that these would be called in all
cases but it
is a possibility.
rob
I guess if config_drive is True then this
isn't really a
problem as
the metadata will be there in the instance
already.
thanks
rob
__________________________________________________________________________
OpenStack Development Mailing List (not for
usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
Sounded like you had this sorted. True?
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
--
Rackspace Australia
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
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:
https://review.openstack.org/#/c/348066/
<https://review.openstack.org/#/c/348066/>
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.
So I think we should get https://review.openstack.org/#/c/348066/
<https://review.openstack.org/#/c/348066/> merged for Newton and
work on what to do about unauthenticated requests from the
instance as a future enhancement.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
--
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
