Merge "Delete PKI middleware debugging section"
This commit is contained in:
Zuul
Gerrit Code Review
commit
002128208c
@ -21,127 +21,3 @@ ideally show an error that explains why an authorization request failed.
|
||||
If you do not see the request in the logs, run keystone with the
|
||||
``--debug`` parameter. Pass the ``--debug`` parameter before the
|
||||
command parameters.
|
||||
|
||||
Debug PKI middleware
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
If you receive an ``Invalid OpenStack Identity Credentials`` message when
|
||||
you accessing and reaching an OpenStack service, it might be caused by
|
||||
the changeover from UUID tokens to PKI tokens in the Grizzly release.
|
||||
|
||||
The PKI-based token validation scheme relies on certificates from
|
||||
Identity that are fetched through HTTP and stored in a local directory.
|
||||
The location for this directory is specified by the ``signing_dir``
|
||||
configuration option.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
In your services configuration file, look for a section like this:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[keystone_authtoken]
|
||||
signing_dir = /var/cache/glance/api
|
||||
www_authenticate_uri = http://controller:5000/v2.0
|
||||
identity_uri = http://controller:35357
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
|
||||
The first thing to check is that the ``signing_dir`` does, in fact,
|
||||
exist. If it does, check for certificate files:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ls -la /var/cache/glance/api/
|
||||
|
||||
total 24
|
||||
drwx------. 2 ayoung root 4096 Jul 22 10:58 .
|
||||
drwxr-xr-x. 4 root root 4096 Nov 7 2012 ..
|
||||
-rw-r-----. 1 ayoung ayoung 1424 Jul 22 10:58 cacert.pem
|
||||
-rw-r-----. 1 ayoung ayoung 15 Jul 22 10:58 revoked.pem
|
||||
-rw-r-----. 1 ayoung ayoung 4518 Jul 22 10:58 signing_cert.pem
|
||||
|
||||
This directory contains two certificates and the token revocation list.
|
||||
If these files are not present, your service cannot fetch them from
|
||||
Identity. To troubleshoot, try to talk to Identity to make sure it
|
||||
correctly serves files, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ curl http://localhost:35357/v2.0/certificates/signing
|
||||
|
||||
This command fetches the signing certificate:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
Certificate:
|
||||
Data:
|
||||
Version: 3 (0x2)
|
||||
Serial Number: 1 (0x1)
|
||||
Signature Algorithm: sha1WithRSAEncryption
|
||||
Issuer: C=US, ST=Unset, L=Unset, O=Unset, CN=www.example.com
|
||||
Validity
|
||||
Not Before: Jul 22 14:57:31 2013 GMT
|
||||
Not After : Jul 20 14:57:31 2023 GMT
|
||||
Subject: C=US, ST=Unset, O=Unset, CN=www.example.com
|
||||
|
||||
Note the expiration dates of the certificate:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Not Before: Jul 22 14:57:31 2013 GMT
|
||||
Not After : Jul 20 14:57:31 2023 GMT
|
||||
|
||||
The token revocation list is updated once a minute, but the certificates
|
||||
are not. One possible problem is that the certificates are the wrong
|
||||
files or garbage. You can remove these files and run another command
|
||||
against your server; they are fetched on demand.
|
||||
|
||||
The Identity service log should show the access of the certificate files. You
|
||||
might have to turn up your logging levels. Set ``debug = True`` in your
|
||||
Identity configuration file and restart the Identity server.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
(keystone.common.wsgi): 2013-07-24 12:18:11,461 DEBUG wsgi __call__
|
||||
arg_dict: {}
|
||||
(access): 2013-07-24 12:18:11,462 INFO core __call__ 127.0.0.1 - - [24/Jul/2013:16:18:11 +0000]
|
||||
"GET http://localhost:35357/v2.0/certificates/signing HTTP/1.0" 200 4518
|
||||
|
||||
If the files do not appear in your directory after this, it is likely
|
||||
one of the following issues:
|
||||
|
||||
* Your service is configured incorrectly and cannot talk to Identity.
|
||||
Check the ``auth_port`` and ``auth_host`` values and make sure that
|
||||
you can talk to that service through cURL, as shown previously.
|
||||
|
||||
* Your signing directory is not writable. Use the ``chmod`` command to
|
||||
change its permissions so that the service (POSIX) user can write to
|
||||
it. Verify the change through ``su`` and ``touch`` commands.
|
||||
|
||||
* The SELinux policy is denying access to the directory.
|
||||
|
||||
SELinux troubles often occur when you use Fedora or RHEL-based packages and
|
||||
you choose configuration options that do not match the standard policy.
|
||||
Run the ``setenforce permissive`` command. If that makes a difference,
|
||||
you should relabel the directory. If you are using a sub-directory of
|
||||
the ``/var/cache/`` directory, run the following command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# restorecon /var/cache/
|
||||
|
||||
If you are not using a ``/var/cache`` sub-directory, you should. Modify
|
||||
the ``signing_dir`` configuration option for your service and restart.
|
||||
|
||||
Set back to ``setenforce enforcing`` to confirm that your changes solve
|
||||
the problem.
|
||||
|
||||
If your certificates are fetched on demand, the PKI validation is
|
||||
working properly. Most likely, the token from Identity is not valid for
|
||||
the operation you are attempting to perform, and your user needs a
|
||||
different role for the operation.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user