Remove security pages
Remove the Security pages as they are being migrated to the charm-guide. Some links need to be changed as a consequence. Add HTML redirects (and tests). The security overview page was completely removed (not migrated) as its contents did not warrant a page of its own. The little it had will be incorporated at a later date. Change-Id: If1bcbb39b4186fac7073f77bc0dacdac4294d3ff
This commit is contained in:
Peter Matulis
parent
52849548d6
commit
d144e9df2e
|
|
@ -15,6 +15,7 @@ RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-eras
|
|||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-manila-ganesha.html$ /project-deploy-guide/charm-deployment-guide/$1/manila-ganesha.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-ovn.html#migration-from-neutron-ml2-ovs-to-ml2-ovn$ /project-deploy-guide/charm-deployment-guide/$1/ovn-migration.html
|
||||
|
||||
# Migration to charm-guide
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-managing-power-events.html$ /charm-guide/$1/admin/managing-power-events.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/deferred-events.html$ /charm-guide/$1/admin/deferred-events.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-policy-overrides.html$ /charm-guide/$1/admin/policy-overrides.html
|
||||
|
|
@ -37,3 +38,5 @@ RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-ovn.
|
|||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-octavia.html$ /charm-guide/$1/admin/networking/load-balancing.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-hardware-offload.html$ /charm-guide/$1/admin/networking/hardware-offloading.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/configure-bridge.html$ /charm-guide/$1/admin/networking/interface-config.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/app-certificate-management.html$ /charm-guide/$1/admin/security/tls.html
|
||||
RedirectMatch 301 ^/project-deploy-guide/charm-deployment-guide/([^/]+)/keystone.html$ /charm-guide/$1/admin/security/keystone.html
|
||||
|
|
|
|||
|
|
@ -1,335 +0,0 @@
|
|||
=========================
|
||||
Managing TLS certificates
|
||||
=========================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The encryption of API endpoints in an OpenStack cloud requires a method for the
|
||||
creation and distribution of TLS certificates, as well as the management of a
|
||||
certificate authority (CA). Charmed OpenStack supports two ways of doing this:
|
||||
|
||||
#. on a per-model basis (using the vault application)
|
||||
#. on a per-application basis (using charm configuration options)
|
||||
|
||||
.. note::
|
||||
|
||||
The recommended way to manage TLS in Charmed OpenStack is with Vault. It is
|
||||
a centrally managed encryption solution, it is designed for the task, and it
|
||||
integrates well with charms.
|
||||
|
||||
Certificate management with Vault
|
||||
---------------------------------
|
||||
|
||||
First ensure that Vault is deployed to the model containing the cloud and the
|
||||
required post-deployment steps have been completed. See the `vault`_ charm
|
||||
README for instructions.
|
||||
|
||||
The next step is to add a CA certificate to the model.
|
||||
|
||||
.. _add_ca_certificate:
|
||||
|
||||
Add a CA certificate
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For Vault to be able to issue certificates on your behalf you must equip it
|
||||
with a CA certificate. This is done in **one** of two ways:
|
||||
|
||||
#. a Vault-generated self-signed root CA certificate
|
||||
#. a third-party intermediate CA certificate
|
||||
|
||||
The Vault method is by far the simpler of the two.
|
||||
|
||||
Self-signed root CA certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To have Vault generate a self-signed root CA certificate:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader generate-root-ca
|
||||
|
||||
You're done.
|
||||
|
||||
Third-party intermediate CA certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The supported workflow for a third-party certificate involves three steps:
|
||||
|
||||
#. retrieve a Certificate Signing Request (CSR) for an intermediate CA from
|
||||
Vault
|
||||
#. transfer the CSR to an external CA to have a signed certificate created
|
||||
#. upload certificate information to Vault
|
||||
|
||||
Retrieve a CSR from Vault
|
||||
.........................
|
||||
|
||||
To retrieve a Vault-generated CSR run the ``get-csr`` action on the leader
|
||||
unit:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader get-csr
|
||||
|
||||
.. note::
|
||||
|
||||
The CSR may be rejected by the signing CA due to incorrect values for
|
||||
certain properties (e.g. common-name). It would be prudent therefore to
|
||||
inquire before generating the CSR. Use command :command:`juju actions
|
||||
--schema vault` for help on setting properties with action ``get-csr``.
|
||||
|
||||
This will produce output similar to:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
unit-vault-0:
|
||||
UnitId: vault/0
|
||||
id: "8"
|
||||
results:
|
||||
Stdout: |
|
||||
lxc
|
||||
lxc
|
||||
active
|
||||
lxc
|
||||
output: |-
|
||||
-----BEGIN CERTIFICATE REQUEST-----
|
||||
MIICijCCAXICAQAwRTFDMEEGA1UEAxM6VmF1bHQgSW50ZXJtZWRpYXRlIENlcnRp
|
||||
ZmljYXRlIEF1dGhvcml0eSAoY2hhcm0tcGtpLWxvY2FsKTCCASIwDQYJKoZIhvcN
|
||||
AQEBBQADggEPADCCAQoCggEBAJvof3Gut71YY9Ke3TlAYT+AoVUu8w0q2DKGh7dL
|
||||
5mUggcvThZuckbuj8IJZZ3pl5D114REcRRH9DIRxp4tH0TSmnb0PJLdjnuLyMQqy
|
||||
/IEipmSQWiILBF8c/QjYqEkvUoprADeJ+9L9KGc/axwuIoLWHqaXLnkSFzypgyz+
|
||||
9Qvxir4wSPvyygZVUDJvUoEekk/sMBidzpEaKuMF7U+aZAdlZvEPr39FilEwcUgQ
|
||||
EY2m3bDDe5maNcD6+la95ENuo0kuHF6wkjXuLGkzDV5xYBMtSO8sqymwRA1CPLyr
|
||||
WIA+ciDQ11Hy+1Q+YTurOoWzmr48QPlamCZEIz8BZeuf8vsCAwEAAaAAMA0GCSqG
|
||||
SIb3DQEBCwUAA4IBAQAoPhk5k5nXpFSYfbsOvm8Rc0hHUTfEHgB4xcQfzMrMTDMX
|
||||
fVmiJjGQhiM1q+eKNLLTDxuOGBBbyniQsveV6JZwpOlkOZ1YVdkw0EoaQndz6dEA
|
||||
JNjjelV2z1FxppKT3504uX/YkASTDnpb63aknE4W3C5aZSvyx/qw/WdUauCNnYoV
|
||||
NdFrzy0p2qm8kXwPsbjIwZTq/AqQ4t7UrNoXoONcxjAdq5UpuoBxgbRJJ7zr1RJp
|
||||
NUhVk/1qi9EQSGeigkuzGGPeRdBXvw4NXAXwnQfCiIBHgLEfkE3PVHNbXfVYqtjC
|
||||
3D2eeYPraKcSJIEts4DCJnbhj5FEzi1km9QgSZgA
|
||||
-----END CERTIFICATE REQUEST-----
|
||||
status: completed
|
||||
timing:
|
||||
completed: 2021-02-16 22:40:12 +0000 UTC
|
||||
enqueued: 2021-02-16 22:40:08 +0000 UTC
|
||||
started: 2021-02-16 22:40:09 +0000 UTC
|
||||
|
||||
Place the CSR data (minus any leading whitespace) in a file, say
|
||||
``~/csr_file``. In this example, the file's contents would be:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
-----BEGIN CERTIFICATE REQUEST-----
|
||||
MIICijCCAXICAQAwRTFDMEEGA1UEAxM6VmF1bHQgSW50ZXJtZWRpYXRlIENlcnRp
|
||||
ZmljYXRlIEF1dGhvcml0eSAoY2hhcm0tcGtpLWxvY2FsKTCCASIwDQYJKoZIhvcN
|
||||
AQEBBQADggEPADCCAQoCggEBAJvof3Gut71YY9Ke3TlAYT+AoVUu8w0q2DKGh7dL
|
||||
5mUggcvThZuckbuj8IJZZ3pl5D114REcRRH9DIRxp4tH0TSmnb0PJLdjnuLyMQqy
|
||||
/IEipmSQWiILBF8c/QjYqEkvUoprADeJ+9L9KGc/axwuIoLWHqaXLnkSFzypgyz+
|
||||
9Qvxir4wSPvyygZVUDJvUoEekk/sMBidzpEaKuMF7U+aZAdlZvEPr39FilEwcUgQ
|
||||
EY2m3bDDe5maNcD6+la95ENuo0kuHF6wkjXuLGkzDV5xYBMtSO8sqymwRA1CPLyr
|
||||
WIA+ciDQ11Hy+1Q+YTurOoWzmr48QPlamCZEIz8BZeuf8vsCAwEAAaAAMA0GCSqG
|
||||
SIb3DQEBCwUAA4IBAQAoPhk5k5nXpFSYfbsOvm8Rc0hHUTfEHgB4xcQfzMrMTDMX
|
||||
fVmiJjGQhiM1q+eKNLLTDxuOGBBbyniQsveV6JZwpOlkOZ1YVdkw0EoaQndz6dEA
|
||||
JNjjelV2z1FxppKT3504uX/YkASTDnpb63aknE4W3C5aZSvyx/qw/WdUauCNnYoV
|
||||
NdFrzy0p2qm8kXwPsbjIwZTq/AqQ4t7UrNoXoONcxjAdq5UpuoBxgbRJJ7zr1RJp
|
||||
NUhVk/1qi9EQSGeigkuzGGPeRdBXvw4NXAXwnQfCiIBHgLEfkE3PVHNbXfVYqtjC
|
||||
3D2eeYPraKcSJIEts4DCJnbhj5FEzi1km9QgSZgA
|
||||
-----END CERTIFICATE REQUEST-----
|
||||
|
||||
Have the CSR signed
|
||||
...................
|
||||
|
||||
The procedure for obtaining a signed certificate from an external CA is
|
||||
particular to the given CA, but it always entails sending the CSR to the CA
|
||||
(typically from its website) and waiting for a reply.
|
||||
|
||||
For informational purposes, an example CLI command is provided below. The exact
|
||||
command syntax is dependent upon the CA. Note the inclusion of the input file
|
||||
``~/csr_file``:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 3650 \
|
||||
-notext -md sha256 -in ~/csr_file -out ~/vault-charm-int.pem -batch \
|
||||
-passin pass:secretpassword
|
||||
|
||||
.. note::
|
||||
|
||||
Depending on the services deployed on your cloud, the intermediate CA
|
||||
may need to issue both client and server certificates. Therefore, it is
|
||||
necessary to check the property of your external CA and grant the
|
||||
intermediate CA the proper level of authorization to issue both types
|
||||
of certificates.
|
||||
|
||||
The certificate is normally provided in PEM format, like the output file
|
||||
``~/vault-charm-int.pem`` in the above command. A root CA certificate should
|
||||
also be provided and placed in, say, file ``~/root-ca.pem``.
|
||||
|
||||
Upload the signed certificate and the root CA certificate to Vault
|
||||
..................................................................
|
||||
|
||||
To upload certificate information to Vault run the ``upload-signed-csr``
|
||||
action on the leader unit:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader upload-signed-csr \
|
||||
pem="$(cat ~/vault-charm-int.pem | base64)" \
|
||||
root-ca="$(cat ~/root-ca.pem | base64)" \
|
||||
allowed-domains='openstack.local'
|
||||
|
||||
The file that the ``pem`` parameter refers to must contain a PEM bundle
|
||||
consisting of:
|
||||
|
||||
#. the signed certificate
|
||||
#. any other intermediate CA certificates
|
||||
#. the root CA certificate
|
||||
|
||||
The file that the ``root-ca`` parameter refers to must contain a PEM bundle
|
||||
consisting of:
|
||||
|
||||
#. any other intermediate CA certificates
|
||||
#. the root CA certificate
|
||||
|
||||
.. important::
|
||||
|
||||
Omitting the (other) intermediate certificate information will result in the
|
||||
new certificate being rejected (due to an incomplete trust chain).
|
||||
|
||||
See the following resources:
|
||||
|
||||
* `RFC5280`_: for details concerning certificate paths and trust
|
||||
* `RFC7468`_: for details on the format of certificate PEM bundles
|
||||
|
||||
Issuing of certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Now that Vault is in possession of a CA certificate it will be able to issue
|
||||
certificates to clients (API services). Client requests are made via the
|
||||
``vault:certificates`` relation. For example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju add-relation keystone:certificates vault:certificates
|
||||
juju add-relation nova-cloud-controller:certificates vault:certificates
|
||||
juju add-relation cinder:certificates vault:certificates
|
||||
juju add-relation neutron-api:certificates vault:certificates
|
||||
juju add-relation glance:certificates vault:certificates
|
||||
|
||||
A request will result in the transfer of certificates and keys from Vault. The
|
||||
corresponding API endpoint will also be updated in Keystone's service catalogue
|
||||
list to reflect that it is now using HTTPS. The service is now TLS-enabled.
|
||||
|
||||
A special client is mysql-innodb-cluster, the cloud database. It has a
|
||||
self-signed certificate but it is recommended to use the one signed by Vault's
|
||||
CA:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju add-relation mysql-innodb-cluster:certificates vault:certificates
|
||||
|
||||
.. important::
|
||||
|
||||
Once Keystone is TLS-enabled every application that talks to Keystone (i.e.
|
||||
there exists a relation between the two) **must** be in possession of the
|
||||
CA certificate. This is achieved as a side-effect when enabling TLS for that
|
||||
application.
|
||||
|
||||
Verification
|
||||
~~~~~~~~~~~~
|
||||
|
||||
To verify the CA certificate begin by sourcing the cloud init file and
|
||||
inspecting the certificate's location and the Keystone API endpoint. The latter
|
||||
should be using HTTPS:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
source novarc
|
||||
env | grep -e OS_AUTH_URL -e OS_CACERT
|
||||
|
||||
Sample output is:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
OS_CACERT=/home/ubuntu/snap/openstackclients/common/root-ca.crt
|
||||
OS_AUTH_URL=https://10.0.0.215:5000/v3
|
||||
|
||||
API services can now be queried by referring explicitly to the certificate. The
|
||||
below tests correspond to the clients mentioned in the previous section:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
# Keystone
|
||||
openstack --os-cacert $OS_CACERT catalog list
|
||||
# Nova
|
||||
openstack --os-cacert $OS_CACERT server list
|
||||
# Cinder
|
||||
openstack --os-cacert $OS_CACERT volume list
|
||||
# Neutron
|
||||
openstack --os-cacert $OS_CACERT network list
|
||||
# Glance
|
||||
openstack --os-cacert $OS_CACERT image list
|
||||
|
||||
Reissuing of certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
New certificates can be reissued to all TLS-enabled clients by means of the
|
||||
``reissue-certificates`` action. See cloud operation `Reissue TLS
|
||||
certificates across the cloud`_ in the Admin Guide for details.
|
||||
|
||||
Switching between different types of CA certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is possible to switch between a self-signed root CA certificate
|
||||
and a third-party intermediate CA certificate after deployment.
|
||||
|
||||
.. Important::
|
||||
|
||||
Switching certificates will cause a short period of downtime for services
|
||||
using Vault as the certificate manager. Notably, a TLS-enabled Keystone will
|
||||
temporarily move to the ``maintainance`` state to update its endpoints.
|
||||
|
||||
From self-signed root certificate to third-party intermediate certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To switch from a self-signed root CA certificate to a third-party intermediate
|
||||
CA certificate, you need to first disable the PKI secrets
|
||||
backend:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader disable-pki
|
||||
|
||||
This step deletes the existing root certificate and invalidates any previous csr
|
||||
requests.
|
||||
|
||||
Next, follow the steps described in the
|
||||
`Third-party intermediate CA certificate`_ section above to retrieve a CSR
|
||||
from the Vault and have it signed by the external CA.
|
||||
|
||||
|
||||
Finally, upload both the signed intermediate certificate and the external root
|
||||
CA certificate to Vault:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader upload-signed-csr \
|
||||
pem=“$(cat /path/to/vault-charm-int.pem | base64)" \
|
||||
root-ca="$(cat /path/to/root-ca.pem | base64)"
|
||||
|
||||
From third-party intermediate certificate to self-signed root certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To switch from an external certificate to a self-signed one first disable the
|
||||
PKI secrets backend and then generate a root CA certificate:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader disable-pki
|
||||
juju run-action --wait vault/leader generate-root-ca
|
||||
|
||||
.. LINKS
|
||||
.. _RFC5280: https://tools.ietf.org/html/rfc5280#section-3.2
|
||||
.. _RFC7468: https://tools.ietf.org/html/rfc7468#section-5
|
||||
.. _vault: https://opendev.org/openstack/charm-vault/src/branch/master/src/README.md
|
||||
.. _Reissue TLS certificates across the cloud: https://docs.openstack.org/charm-guide/latest/admin/ops-reissue-tls-certs.html
|
||||
|
|
@ -32,14 +32,6 @@ OpenStack Charms usage. To help improve it you can `file an issue`_ or
|
|||
upgrade-special
|
||||
upgrade-issues
|
||||
|
||||
.. toctree::
|
||||
:caption: Security
|
||||
:maxdepth: 1
|
||||
|
||||
Overview <security-overview>
|
||||
keystone
|
||||
app-certificate-management
|
||||
|
||||
.. LINKS
|
||||
.. _file an issue: https://bugs.launchpad.net/charm-deployment-guide/+filebug
|
||||
.. _submit a contribution: https://opendev.org/openstack/charm-deployment-guide
|
||||
|
|
|
|||
|
|
@ -1,205 +0,0 @@
|
|||
.. role:: raw-html(raw)
|
||||
:format: html
|
||||
|
||||
========
|
||||
Keystone
|
||||
========
|
||||
|
||||
Security compliance
|
||||
-------------------
|
||||
|
||||
The keystone charm's ``password-security-compliance`` configuration option sets
|
||||
the ``[security_compliance]`` section of Keystone's configuration file. The
|
||||
value of this option is a YAML dictionary that includes support for the
|
||||
following keys (value formats and units are also included).
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
change_password_upon_first_use: <boolean>
|
||||
disable_user_account_days_inactive: <int> (days)
|
||||
lockout_duration: <int> (seconds)
|
||||
lockout_failure_attempts: <int>
|
||||
minimum_password_age: <int> (days)
|
||||
password_expires_days: <int> (days)
|
||||
password_regex: <string>
|
||||
password_regex_description: <string>
|
||||
unique_last_password_count: <int>
|
||||
|
||||
.. important::
|
||||
|
||||
The upstream document `Security compliance and PCI-DSS`_ should be consulted
|
||||
before setting any of these options.
|
||||
|
||||
The configuration is typically contained within a file, say ``config.yaml``.
|
||||
For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
password-security-compliance:
|
||||
change_password_upon_first_use: True
|
||||
lockout_duration: 1800
|
||||
lockout_failure_attempts: 3
|
||||
...
|
||||
|
||||
It is applied in the usual way:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju config keystone --file config.yaml
|
||||
|
||||
The charm will protect service accounts (accounts requested by other units that
|
||||
are in the service domain) against being forced to change their password.
|
||||
Operators should also ensure that any other accounts are protected as per the
|
||||
above referenced note.
|
||||
|
||||
Operators should also ensure that any non-service accounts are protected as per
|
||||
the upstream document.
|
||||
|
||||
The charm will enter a blocked state if the value of charm option
|
||||
``password-security-compliance`` is not in valid YAML format and/or the
|
||||
individual service options do not conform to the proper value formats.
|
||||
|
||||
.. _keyston_tokens:
|
||||
|
||||
Token support
|
||||
-------------
|
||||
|
||||
Over time OpenStack has come to support two Keystone token formats: UUID and
|
||||
Fernet.
|
||||
|
||||
Fernet tokens were added to address the issue of size observed with PKI and
|
||||
PKIZ tokens in addition to continuing the Keystone behaviour of persisting
|
||||
tokens to a common database cluster (like UUID tokens). For more information
|
||||
see this `Fernet FAQ`_.
|
||||
|
||||
.. important::
|
||||
|
||||
Starting with OpenStack Rocky, only the Fernet format for authentication
|
||||
tokens is supported. This is documented as a `known upgrade issue`_.
|
||||
|
||||
Fernet keys
|
||||
-----------
|
||||
|
||||
Theory of operation
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Keystone generates Fernet keys, which in turn are used to generate/encrypt
|
||||
and decode/decrypt Fernet tokens.
|
||||
|
||||
There are three key types, and each is associated with a naming scheme that is
|
||||
applied to the directories in which they are found. Directory names are based
|
||||
on integers:
|
||||
|
||||
* primary key
|
||||
* integer: the highest one
|
||||
* generates tokens
|
||||
* number of keys: one
|
||||
|
||||
* staged key
|
||||
* integer: '0'
|
||||
* will become the next primary key
|
||||
* can decode tokens
|
||||
* number of keys: one
|
||||
|
||||
* secondary key
|
||||
* integer: any other number
|
||||
* was previously a primary key
|
||||
* can decode tokens
|
||||
* number of keys: one or more
|
||||
|
||||
Each key type must be present at all times. This means Keystone uses a minimum
|
||||
of three keys.
|
||||
|
||||
Key rotation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Key rotation refers to the process by which two keys assume a different type,
|
||||
one key gets created, and typically one key gets removed:
|
||||
|
||||
#. staged :raw-html:`→` primary
|
||||
#. primary :raw-html:`→` secondary
|
||||
#. the staged is created
|
||||
#. a secondary is removed
|
||||
|
||||
A key will get removed if the total number of keys surpasses the specified
|
||||
maximum allowed (more on this later).
|
||||
|
||||
This process takes place on the master keystone unit and takes into account
|
||||
three aspects:
|
||||
|
||||
* rotation frequency
|
||||
* token expiration
|
||||
* maximum number of active keys
|
||||
|
||||
These are related according to this formula:
|
||||
|
||||
.. math::
|
||||
|
||||
max\_active\_keys = \frac{ token\_expiration }{ rotation\_frequency } + 2
|
||||
|
||||
In the keystone charm, token expiration and the maximum number of active keys
|
||||
are specified, respectively, with the ``token-expiration`` and the
|
||||
``fernet-max-active-keys`` configuration options.
|
||||
|
||||
For example, given that an administrator desires a token expiration of 1 hour
|
||||
(3600 seconds) and a rotation frequency of 15 minutes (900 seconds), the maximum
|
||||
number of active keys must be six:
|
||||
|
||||
.. math::
|
||||
|
||||
\begin{eqnarray}
|
||||
max\_active\_keys &=& \frac{ 3600 }{ 900 } + 2\\
|
||||
&=& 4+2\\
|
||||
&=& 6\\
|
||||
\end{eqnarray}
|
||||
|
||||
The above two options can then be set accordingly:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
token-expiration: 3600
|
||||
fernet-max-active-keys: 6
|
||||
|
||||
Rotation frequency
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
From the point of view of rotation frequency:
|
||||
|
||||
.. math::
|
||||
|
||||
rotation\_frequency = \frac{ token\_expiration }{ max\_active\_keys - 2 }
|
||||
|
||||
Since the denominator must lead to a positive real number for rotation
|
||||
frequency the value of ``fernet-max-active-keys`` must be at least three, and
|
||||
this constraint is enforced by the charm.
|
||||
|
||||
To increase rotation frequency either decrease ``fernet-max-active-keys`` or
|
||||
increase ``token-expiration``. To decrease rotation frequency, do the opposite.
|
||||
|
||||
The most notable effect of increasing rotation frequency is the reduction in
|
||||
key lifetime (secondary keys get removed more often).
|
||||
|
||||
Default values
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
These are the default values for these keystone charm options and the resulting
|
||||
default rotation frequency:
|
||||
|
||||
* ``token-expiration``: 3600 sec (1 hour)
|
||||
* ``fernet-max-active-keys``: 3
|
||||
* ``rotation frequency``: 3600 sec (1 hour)
|
||||
|
||||
Token validation breakage
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Token validation breakage is a situation in which a decoding key is no longer
|
||||
available to validate an unexpired token. This can be caused by a rotation
|
||||
frequency that has been set too high (a very short key lifetime) or by keys
|
||||
failing to synchronise (from the master keystone unit to the other units) prior
|
||||
to the succeeding rotation. Incremental changes to rotation frequency is
|
||||
therefore advised.
|
||||
|
||||
.. LINKS
|
||||
.. _Security compliance and PCI-DSS: https://docs.openstack.org/keystone/latest/admin/configuration.html#security-compliance-and-pci-dss
|
||||
.. _Fernet FAQ: https://docs.openstack.org/keystone/pike/admin/identity-fernet-token-faq.html
|
||||
.. _known upgrade issue: upgrade-issues.html#keystone-and-fernet-tokens-upgrading-from-queens-to-rocky
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
=================
|
||||
Security overview
|
||||
=================
|
||||
|
||||
This Security section includes topics related to authentication and
|
||||
authorisation in Charmed OpenStack.
|
||||
|
||||
.. note::
|
||||
|
||||
Charmed OpenStack assumes a backing cloud type of MAAS. This precludes the
|
||||
use of the :command:`juju expose` command for opening firewall ports since
|
||||
MAAS does not implement a firewall.
|
||||
|
||||
.. LINKS
|
||||
|
|
@ -28,7 +28,7 @@
|
|||
/project-deploy-guide/charm-deployment-guide/latest/placement-charm-upgrade-to-train.html 301 /project-deploy-guide/charm-deployment-guide/latest/uprade-stein-to-train.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-ovn.html#migration-from-neutron-ml2-ovs-to-ml2-ovn 301 /project-deploy-guide/charm-deployment-guide/latest/ovn-migration.html
|
||||
|
||||
## charm guide
|
||||
# Migration to charm-guide
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-managing-power-events.html 301 /charm-guide/latest/admin/managing-power-events.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/deferred-events.html 301 /charm-guide/latest/admin/deferred-events.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-policy-overrides.html 301 /charm-guide/latest/admin/policy-overrides.html
|
||||
|
|
@ -50,3 +50,5 @@
|
|||
/project-deploy-guide/charm-deployment-guide/latest/app-octavia.html 301 /charm-guide/latest/admin/networking/load-balancing.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-hardware-offload.html 301 /charm-guide/latest/admin/networking/hardware-offloading.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/configure-bridge.html 301 /charm-guide/latest/admin/networking/interface-config.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html 301 /charm-guide/latest/admin/security/tls.html
|
||||
/project-deploy-guide/charm-deployment-guide/latest/keystone.html 301 /charm-guide/latest/admin/security/keystone.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue