[openstack-dev] [neutron] Credentials for a Keystone DB lookup from Neutron

Neil Jerram neil at tigera.io
Wed Aug 1 14:14:02 UTC 2018


Hoping I can leverage the wisdom of the ML for a follow-up point on this
topic...

I've coded this up now following Aditya's suggestion, but the issue now is
about the Neutron user (or more generally, whatever is configured in
neutron.conf's [keystone_authtoken] section) being authorized to do a
keystone.projects.list().

IIUC that is considered to be an admin operation, and the Neutron user is
not normally authorized to do it.  However, it seems reasonable to me that
the operator of a particular deployment can choose to allow that if they
want to, and I see two approaches to doing that:

1. Add the "admin" role to the "neutron" user.  I have code for this that
seems to work, and append it below for interest and review [1].

2. Modify Keystone's RBAC specifically to allow "neutron" to do
"get_projects".  I don't yet know how to do this, though.

My questions are:  Am I in the right ballpark here?  Are there any other
approaches to allowing this access, ideally as specifically as possible?
And in case (2) is the preferred approach, can you point me to how to
modify that RBAC?

Many thanks,
     Neil


[1] Apparently working code for adding the "admin" role to the "neutron"
user:

# Admin client setup:
>>> auth_url="http://controller:35357/v3"
>>> name = "admin"
>>> password = "abcdef"
>>> from keystoneauth1 import identity
>>> auth = identity.Password(auth_url=auth_url,
...                          username=name,
...                          password=password,
...                          project_name=name,
...                          project_domain_id="default",
...                          user_domain_id="default")
>>> from keystoneauth1 import session
>>> session = session.Session(auth=auth)
>>> from keystoneclient.v3.client import Client as KeystoneClient
>>> keystone_client = KeystoneClient(session=session)

# Identify which role is the "admin" one:
>>> roles=keystone_client.roles.list()
>>> roles[0]
<Role domain_id=None, id=9fe2ff9ee4384b1894a90878d3e92bab, links={u'self':
u'http://controller:35357/v3/roles/9fe2ff9ee4384b1894a90878d3e92bab'},
name=_member_>
>>> roles[1]
<Role domain_id=None, id=d0a84ecdad284fecb9b215126b5fbe05, links={u'self':
u'http://controller:35357/v3/roles/d0a84ecdad284fecb9b215126b5fbe05'},
name=admin>

# Identify which project is the "service" one:
>>> projects=keystone_client.projects.list()
>>> projects[0]
<Project description=Bootstrap project for initializing the cloud.,
domain_id=default, enabled=True, id=6274ae6b92634389a4a5eda4093035c3,
is_domain=False, links={u'self': u'
http://controller:35357/v3/projects/6274ae6b92634389a4a5eda4093035c3'},
name=admin, parent_id=default, tags=[]>
>>> projects[1]
<Project description=Service Project, domain_id=default, enabled=True,
id=7837dbe6b5294ce89342dec823fea106, is_domain=False, links={u'self': u'
http://controller:35357/v3/projects/7837dbe6b5294ce89342dec823fea106'},
name=service, parent_id=default, tags=[]>

# Identify which user is the "neutron" one:
>>> users=keystone_client.users.list()
>>> users[0]
<User domain_id=default, enabled=True, id=113dc98e751d4720b4573044df6eb870,
links={u'self': u'
http://controller:35357/v3/users/113dc98e751d4720b4573044df6eb870'},
name=neutron, options={}, password_expires_at=None>

# Grant "admin" role to "neutron":
>>> keystone_client.roles.grant(roles[1], user=users[0],
project=projects[1])

# And to revoke that again:
>>> keystone_client.roles.revoke(roles[1], user=users[0],
project=projects[1])




On Tue, Jul 17, 2018 at 7:17 PM Neil Jerram <neil at tigera.io> wrote:

> Thanks Aditya, that looks like just what I need.
>
> Best wishes,
>     Neil
>
>
> On Tue, Jul 17, 2018 at 5:48 PM Aditya Vaja <wolverine.av at gmail.com>
> wrote:
>
>> hey neil,
>>
>> neutron.conf has a section called '[keystone_authtoken]’ which has
>> credentials to query keystone as neutron. you can read the config as you’d
>> typically do from the mechanism driver for any other property using
>> oslo.config.
>>
>> you could then use python-keystoneclient with those creds to query the
>> mapping. a sample is given in the keystoneclient repo [1].
>>
>> via telegram
>>
>> [1]
>> https://github.com/openstack/python-keystoneclient/blob/650716d0dd30a73ccabe3f0ec20eb722ca0d70d4/keystoneclient/v3/client.py#L102-L116
>> On Tue, Jul 17, 2018 at 9:58 PM, Neil Jerram <neil at tigera.io> wrote:
>>
>> On Tue, Jul 17, 2018 at 3:55 PM Jay Pipes <jaypipes at gmail.com> wrote:
>>
>>> On 07/17/2018 03:36 AM, Neil Jerram wrote:
>>> > Can someone help me with how to look up a project name (aka tenant
>>> name)
>>> > for a known project/tenant ID, from code (specifically a mechanism
>>> > driver) running in the Neutron server?
>>> >
>>> > I believe that means I need to make a GET REST call as here:
>>> >
>>> https://developer.openstack.org/api-ref/identity/v3/index.html#projects.
>>> But
>>> > I don't yet understand how a piece of Neutron server code can ensure
>>> > that it has the right credentials to do that. If someone happens to
>>> > have actual code for doing this, I'm sure that would be very helpful.
>>> >
>>> > (I'm aware that whenever the Neutron server processes an API request,
>>> > the project name for the project that generated that request is added
>>> > into the request context. That is great when my code is running in an
>>> > API request context. But there are other times when the code isn't in
>>> a
>>> > request context and still needs to map from a project ID to project
>>> > name; hence the question here.)
>>>
>>> Hi Neil,
>>>
>>> You basically answered your own question above :) The neutron request
>>> context gets built from oslo.context's Context.from_environ() [1] which
>>> has this note in the implementation [2]:
>>>
>>> # Load a new context object from the environment variables set by
>>> # auth_token middleware. See:
>>> #
>>>
>>> https://docs.openstack.org/keystonemiddleware/latest/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
>>>
>>> So, basically, simply look at the HTTP headers for HTTP_X_PROJECT_NAME.
>>> If you don't have access to a HTTP headers, then you'll need to pass
>>> some context object/struct to the code you're referring to. Might as
>>> well pass the neutron RequestContext (derived from oslo_context.Context)
>>> to the code you're referring to and you get all this for free.
>>>
>>> Best,
>>> -jay
>>>
>>> [1]
>>>
>>> https://github.com/openstack/oslo.context/blob/4abd5377e4d847102a4e87a528d689e31cc1713c/oslo_context/context.py#L424
>>>
>>> [2]
>>>
>>> https://github.com/openstack/oslo.context/blob/4abd5377e4d847102a4e87a528d689e31cc1713c/oslo_context/context.py#L433-L435
>>
>>
>> Many thanks for this reply, Jay.
>>
>> If I'm understanding fully, I believe it all works beautifully so long as
>> the Neutron server is processing a specific API request, e.g. a port CRUD
>> operation. Then, as you say, the RequestContext includes the name of the
>> project/tenant that originated that request.
>>
>> I have an additional requirement, though, to do a occasional audit of
>> standing resources in the Neutron DB, and to check that my mechanism
>> driver's programming for them is correct. To do that, I have an independent
>> eventlet thread that runs in admin context and occasionally queries Neutron
>> resources, e.g. all the ports. For each port, the Neutron DB data includes
>> the project_id, but not project_name, and I'd like at that point to be able
>> to map from the project_id for each port to project_name.
>>
>> Do you have any thoughts on how I could do that? (E.g. perhaps there is
>> some way of generating and looping round a request with the project_id,
>> such that the middleware populates the project_name... but that sounds a
>> bit baroque; I would hope that there would be a way of doing a simpler
>> Keystone DB lookup.)
>>
>> Regards,
>> Neil
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
>> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180801/e47a4d24/attachment.html>


More information about the OpenStack-dev mailing list