On 11/24/2015 10:50 AM, Henry Nash wrote:
Some good ideas here, Adam. I would think that some of the real “diagnostic
APIs” might only be available via keystone-manage, rather than an exposed API.
I'd like to get away from the assumption that you have physical access
to the machines to do operations like these. The "config in the
database" approach means that this stuff is going to be far more
dispersed. So, while and Admin-only API might be appropriate, it should
still be remotely accessable.
Henry
On 24 Nov 2015, at 03:07, Adam Young <ayo...@redhat.com> wrote:
Figuring out what is or is not going to work when a user tries to perform an
operation in OpenStack can be frustrating. I've had a few people ask me for
help specifically for configuring LDAP. With Federation , things will get
better. I mean Worse.
What kind of diagnostic tooling do we need? I know the basics:
If I have a known good user in LDAP, can they
Looks like I over edited here. Should have read "can they authenticate
using that account."
. This is the first thing, and it can be done by asking for an unscoped
token.
Once they have an unscoped token, can they get a scoped token? Same as before,
but adding the project ID or domain name/project name to the token request.
OK...what about if the users don't want to give you their password? With LDAP,
we can do OpenStack user show to see if the user is in the backend. With
Federation...not so much.
Recently, I was trying to debug an issue where a server create failed due to
errors in the service to service communication; Neutron could not make the call
it needed to Nova due to the service user not having the Admin role. The thing
is, the service user was not an actual user, but rather a Service principal
authenticate via Kerberos. I think this is an indicator of the things to come.
We need an API that will show, given as set of post-validated credentials,
communicated via Federation, what will the token validation response look like.
We'll need user domain id, user id, project, roles, and service catalog.
What else do we need diagnostically? I know that setting up LDAP is especially
tricky, and multiple LDAP backends, added in live config, using the Database
backend, is going to be particularly painful to troubleshoot. We need to be
able to start with:
Is the LDAP account used to fetch users working properly?
If not, what do the Actual LDAP queries look like? Ideally, something we
could pipe right into ldapsearch to confirm from the command line.
Then, take a real user, and act like they are trying to authenticate, list the
groups they should have, the roles they would be assigned, and the service
catalog. We need this stuff piece by piece, to be able to troubleshoot.
Is there anything I am missing here? We are not going to have the luxury of
cranking up logging and looking at data in a live running server; My friend
Hippa Sarbanes-Oxley has told me point blank that is a no-go.
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
