Wrong IP Address for error message in keystone.log

true, we should have an option for this...

option: http://git.openstack.org/cgit/openstack/nova/tree/nova/api/auth.py#n45
usage: http://git.openstack.org/cgit/openstack/nova/tree/nova/api/auth.py#n128

we should change up keystone wsgi to use this new option:
https://github.com/openstack/keystone/blob/2bad130bf457ab4b23b65f9b407a8cc8bde300fe/keystone/common/wsgi.py#L213

Why is this even an option in other projects? If X-Forwarded-For is set, keystone should use it appropriately, right?

Bug 1554274 (Notification showing VIP ip but not client ip) is closely related.

@dolph, yeah having it as an option doesn't seem necessary, we could just look to see if it's there.

One reason to make it an option is that the value should only be trusted if Keystone is behind a trusted proxy that ensures it is set correctly. Otherwise, a malicious client can set the value to anything (the wrong IP address, unprintable characters, etc). By setting this option, an operator is letting Keystone know the header can be trusted based on the deployment.

Thanks Dave, guess we'll follow the already established pattern

not necessary for rc1

Change abandoned by Steve Martinelli (<email address hidden>) on branch: master
Review: https://review.openstack.org/293575
Reason: track https://review.openstack.org/#/c/309038/1 instead

Fix proposed to branch: master
Review: https://review.openstack.org/309098

Change abandoned by Mikhail Nikolaenko (<email address hidden>) on branch: master
Review: https://review.openstack.org/309098

I have never seen a production deployment where x-forwarded-for and x-forwarded-proto are not set by the proxy/LB. They are required if Keystone cluster is protected by SSL. I would even argue that we don't need make x-forwarded-proto header configurable. They are universal.

Automatically unassigning due to inactivity.

Change abandoned by Boris Bobrov (<email address hidden>) on branch: master
Review: https://review.openstack.org/309038
Reason: probably won't be worked on

Looks like this was resolved in oslo.middleware in this commit: https://github.com/openstack/oslo.middleware/commit/df01234bd864062a1dddd071b1d265153867f4b1

I'm marking it as WONTFIX for keystone and opening it up against oslo.middleware as fix-released

This should be available in Ocata FYI

Actually, I think we still have a TODO in keystone to add it to our pipeline by default, which we probably should do.

Sorry for the flip-flopping, we do include oslo.middleware's http_proxy_to_wsgi in the pipeline by default: https://github.com/openstack/keystone/commit/8b5c095d6f7e4dca93306f00416784303392a67c

This specific feature should be available in Ocata, just set the `[oslo_middleware] enable_proxy_headers_parsing` option to True in keysone.conf if you're using HA