openstack/openstack-manuals
Code Issues Proposed changes

Fixed issue with description list and other typos

Browse Source 
Modified numbering and alignment of list items so that they dont
appear as description list but part of an enumerated list. A small
typo error and grammer was also corrected.

Change-Id: I41210ded8e95d1cd4855a831fb6335a47a737aed
Closes-Bug: #1553832
This commit is contained in:
Rahul Nair 2016-03-07 06:20:42 +00:00
parent 595a7dbb30
commit 56895bfe4b
1 changed files with 43 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
doc/admin-guide-cloud/source/keystone_fernet_token_faq.rst
View File

@ -71,8 +71,8 @@ across a keystone deployment is best handled through configuration management
tooling. Use :command:`keystone-manage fernet_rotate` to rotate the key tooling. Use :command:`keystone-manage fernet_rotate` to rotate the key
repository. repository.
Do fernet tokens still expires? Do fernet tokens still expire?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, fernet tokens can expire just like any other keystone token formats. Yes, fernet tokens can expire just like any other keystone token formats.
@ -147,41 +147,47 @@ distribution should be an operation that can run in succession until it
succeeds. The following might help illustrate the isolation between key succeeds. The following might help illustrate the isolation between key
rotation and key distribution. rotation and key distribution.
1. Ensure all keystone nodes in the deployment have the same key repository. #. Ensure all keystone nodes in the deployment have the same key repository.
2. Pick a keystone node in the cluster to rotate from. #. Pick a keystone node in the cluster to rotate from.
3. Rotate keys. #. Rotate keys.
a) Was is successful?
i) If no, investigate issues with the particular keystone node you #. Was it successful?
rotated keys on. Fernet keys are small and the operation for
rotation is trivial. There should not be much room for error in key #. If no, investigate issues with the particular keystone node you
rotation. It is possible that the user does not have the ability to rotated keys on. Fernet keys are small and the operation for
write new keys to the key repository. Log output from rotation is trivial. There should not be much room for error in key
``keystone-manage fernet_rotate`` should give more information into rotation. It is possible that the user does not have the ability to
specific failures. write new keys to the key repository. Log output from
ii) If yes, you should see a new staged key. The old staged key should ``keystone-manage fernet_rotate`` should give more information into
be the new primary. Depending on the ``max_active_keys`` limit you specific failures.
might have secondary keys that were pruned. At this point, the node
that you rotated on will be creating fernet tokens with a primary #. If yes, you should see a new staged key. The old staged key should
key that all other nodes should have as the staged key. This is why be the new primary. Depending on the ``max_active_keys`` limit you
we checked the state of all key repositories in Step one. All other might have secondary keys that were pruned. At this point, the node
nodes in the cluster should be able to decrypt tokens created with that you rotated on will be creating fernet tokens with a primary
the new primary key. At this point, we are ready to distribute the key that all other nodes should have as the staged key. This is why
new key set. we checked the state of all key repositories in Step one. All other
4. Distribute the new key repository. nodes in the cluster should be able to decrypt tokens created with
a) Was it successful? the new primary key. At this point, we are ready to distribute the
i) If yes, you should be able to confirm that all nodes in the cluster new key set.
have the same key repository that was introduced in Step 3. All
nodes in the cluster will be creating tokens with the primary key #. Distribute the new key repository.
that was promoted in Step 3. No further action is required until the
next schedule key rotation. #. Was it successful?
ii) If no, try distributing again. Remember that we already rotated the
repository and performing another rotation at this point will #. If yes, you should be able to confirm that all nodes in the cluster
result in tokens that cannot be validated across certain hosts. have the same key repository that was introduced in Step 3. All
Specifically, the hosts that did not get the latest key set. You nodes in the cluster will be creating tokens with the primary key
should be able to distribute keys until it is successful. If that was promoted in Step 3. No further action is required until the
certain nodes have issues syncing, it could be permission or next schedule key rotation.
network issues and those should be resolved before subsequent
rotations. #. If no, try distributing again. Remember that we already rotated the
repository and performing another rotation at this point will
result in tokens that cannot be validated across certain hosts.
Specifically, the hosts that did not get the latest key set. You
should be able to distribe keys until it is successful. If certain
nodes have issues syncing, it could be permission or network issues
and those should be resolved before subsequent rotations.
How long should I keep my keys around? How long should I keep my keys around?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~