Files
1d5b1d746e027bb9509ad0e45cc0f2f50d28511f
swift /etc /keymaster.conf-sample

124 lines
6.1 KiB
Plaintext
Raw Normal View History

[keymaster]
py3: Work with proper native string paths in crypto meta Previously, we would work with these paths as WSGI strings -- this would work fine when all data were read and written on the same major version of Python, but fail pretty badly during and after upgrading Python. In particular, if a py3 proxy-server tried to read existing data that was written down by a py2 proxy-server, it would hit an error and respond 500. Worse, if an un-upgraded py2 proxy tried to read data that was freshly-written by a py3 proxy, it would serve corrupt data back to the client (including a corrupt/invalid ETag and Content-Type). Now, ensure that both py2 and py3 write down paths as native strings. Make an effort to still work with WSGI-string metadata, though it can be ambiguous as to whether a string is a WSGI string or not. The heuristic used is if * the path from metadata does not match the (native-string) request path and * the path from metadata (when interpreted as a WSGI string) can be "un-wsgi-fied" without any encode/decode errors and * the native-string path from metadata *does* match the native-string request path then trust the path from the request. By contrast, we usually prefer the path from metadata in case there was a pipeline misconfiguration (see related bug). Add the ability to read and write a new, unambiguous version of metadata that always has the path as a native string. To support rolling upgrades, a new config option is added: meta_version_to_write. This defaults to 2 to support rolling upgrades without configuration changes, but the default may change to 3 in a future release. UpgradeImpact ============= When upgrading from Swift 2.20.0 or Swift 2.19.1 or earlier, set meta_version_to_write = 1 in your keymaster's configuration. Regardless of prior Swift version, set meta_version_to_write = 3 after upgrading all proxy servers. When switching from Python 2 to Python 3, first upgrade Swift while on Python 2, then upgrade to Python 3. Change-Id: I00c6693c42c1a0220b64d8016d380d5985339658 Closes-Bug: #1888037 Related-Bug: #1813725
2020年07月20日 14:18:33 -07:00
# Over time, the format of crypto metadata on disk may change slightly to resolve
# ambiguities. In general, you want to be writing the newest version, but to
# ensure that all writes can still be read during rolling upgrades, there's the
# option to write older formats as well.
# Before upgrading from Swift 2.20.0 or earlier, ensure this is set to 1
# Before upgrading from Swift 2.25.0 or earlier, ensure this is set to at most 2
# After upgrading all proxy servers, set this to 3 (currently the highest version)
# meta_version_to_write = 3
# Sets the root secret from which encryption keys are derived. This must be set
# before first use to a value that is a base64 encoding of at least 32 bytes.
# The security of all encrypted data critically depends on this key, therefore
# it should be set to a high-entropy value. For example, a suitable value may
# be obtained by base-64 encoding a 32 byte (or longer) value generated by a
# cryptographically secure random number generator. Changing the root secret is
# likely to result in data loss. If this option is set, the root secret MUST
# NOT be set in proxy-server.conf.
# encryption_root_secret = changeme
[kms_keymaster]
# The kms_keymaster section is used for configuring a keymaster that retrieves
# the encryption root secret from an external key management system (kms),
# using the Castellan abstraction layer. Castellan can support various kms
# backends that use Keystone for authentication. Currently, the only
# implemented backend is for Barbican.
py3: Work with proper native string paths in crypto meta Previously, we would work with these paths as WSGI strings -- this would work fine when all data were read and written on the same major version of Python, but fail pretty badly during and after upgrading Python. In particular, if a py3 proxy-server tried to read existing data that was written down by a py2 proxy-server, it would hit an error and respond 500. Worse, if an un-upgraded py2 proxy tried to read data that was freshly-written by a py3 proxy, it would serve corrupt data back to the client (including a corrupt/invalid ETag and Content-Type). Now, ensure that both py2 and py3 write down paths as native strings. Make an effort to still work with WSGI-string metadata, though it can be ambiguous as to whether a string is a WSGI string or not. The heuristic used is if * the path from metadata does not match the (native-string) request path and * the path from metadata (when interpreted as a WSGI string) can be "un-wsgi-fied" without any encode/decode errors and * the native-string path from metadata *does* match the native-string request path then trust the path from the request. By contrast, we usually prefer the path from metadata in case there was a pipeline misconfiguration (see related bug). Add the ability to read and write a new, unambiguous version of metadata that always has the path as a native string. To support rolling upgrades, a new config option is added: meta_version_to_write. This defaults to 2 to support rolling upgrades without configuration changes, but the default may change to 3 in a future release. UpgradeImpact ============= When upgrading from Swift 2.20.0 or Swift 2.19.1 or earlier, set meta_version_to_write = 1 in your keymaster's configuration. Regardless of prior Swift version, set meta_version_to_write = 3 after upgrading all proxy servers. When switching from Python 2 to Python 3, first upgrade Swift while on Python 2, then upgrade to Python 3. Change-Id: I00c6693c42c1a0220b64d8016d380d5985339658 Closes-Bug: #1888037 Related-Bug: #1813725
2020年07月20日 14:18:33 -07:00
# Over time, the format of crypto metadata on disk may change slightly to resolve
# ambiguities. In general, you want to be writing the newest version, but to
# ensure that all writes can still be read during rolling upgrades, there's the
# option to write older formats as well.
# Before upgrading from Swift 2.20.0 or earlier, ensure this is set to 1
# Before upgrading from Swift 2.25.0 or earlier, ensure this is set to at most 2
# After upgrading all proxy servers, set this to 3 (currently the highest version)
# meta_version_to_write = 3
# The api_class tells Castellan which key manager to use to access the external
# key management system. The default value that accesses Barbican is
# castellan.key_manager.barbican_key_manager.BarbicanKeyManager.
# api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager
# The configuration options below apply to a Barbican KMS being accessed using
# Castellan. If another KMS type is used (by specifying another value for
# api_class), then other configuration options may be required.
# The key_id is the identifier of the root secret stored in the KMS. For
# details of how to store an existing root secret in Barbican, or how to
# generate a new root secret in Barbican, see the 'overview_encryption'
# documentation.
# The key_id is the final part of the secret href returned in the
# output of an 'openstack secret order get' command after an order to store or
# create a key has been successfully completed. See the 'overview_encryption'
# documentation for more information on this command.
# key_id = changeme
# The Keystone username of the user used to access the key from the KMS. The
# username shall be set to match an existing user.
# username = changeme
# The password to go with the Keystone username above.
# password = changeme
# The Keystone project name. For security reasons, it is recommended to set
# the project_name to a project separate from the service project used by
# other OpenStack services. Thereby, if another service is compromised, it will
# not have access to the Swift root encryption secret. It is recommended that
# the swift user is the only one that has a role in this project.
# project_name = changeme
# Instead of the project name, the project id may also be used.
# project_id = changeme
# The Keystone URL to authenticate to. The value of auth_endpoint may be
# set according to the value of www_authenticate_uri in [filter:authtoken] in
# proxy-server.conf.
# auth_endpoint = http://keystonehost/identity
# The project and user domain names may optionally be specified. If they are
# not specified, the default values of 'Default' (for *_domain_name) and
# 'default' (for *_domain_id) are used (note the capitalization).
# project_domain_name = Default
# user_domain_name = Default
# Instead of the project domain name and user domain name, the project domain
# id and user domain id may also be specified.
# project_domain_id = default
# user_domain_id = default
# The following configuration options may also be used in addition to/instead
# of the above options. Refer to the Keystone documentation for more details
# on the usage of the options: https://docs.openstack.org/keystone/
# user_id = changeme
# trust_id = changeme
# reauthenticate = changeme
# domain_id = changeme
# domain_name = changeme
[kmip_keymaster]
# The kmip_keymaster section is used to configure a keymaster that fetches an
# encryption root secret from a KMIP service.
py3: Work with proper native string paths in crypto meta Previously, we would work with these paths as WSGI strings -- this would work fine when all data were read and written on the same major version of Python, but fail pretty badly during and after upgrading Python. In particular, if a py3 proxy-server tried to read existing data that was written down by a py2 proxy-server, it would hit an error and respond 500. Worse, if an un-upgraded py2 proxy tried to read data that was freshly-written by a py3 proxy, it would serve corrupt data back to the client (including a corrupt/invalid ETag and Content-Type). Now, ensure that both py2 and py3 write down paths as native strings. Make an effort to still work with WSGI-string metadata, though it can be ambiguous as to whether a string is a WSGI string or not. The heuristic used is if * the path from metadata does not match the (native-string) request path and * the path from metadata (when interpreted as a WSGI string) can be "un-wsgi-fied" without any encode/decode errors and * the native-string path from metadata *does* match the native-string request path then trust the path from the request. By contrast, we usually prefer the path from metadata in case there was a pipeline misconfiguration (see related bug). Add the ability to read and write a new, unambiguous version of metadata that always has the path as a native string. To support rolling upgrades, a new config option is added: meta_version_to_write. This defaults to 2 to support rolling upgrades without configuration changes, but the default may change to 3 in a future release. UpgradeImpact ============= When upgrading from Swift 2.20.0 or Swift 2.19.1 or earlier, set meta_version_to_write = 1 in your keymaster's configuration. Regardless of prior Swift version, set meta_version_to_write = 3 after upgrading all proxy servers. When switching from Python 2 to Python 3, first upgrade Swift while on Python 2, then upgrade to Python 3. Change-Id: I00c6693c42c1a0220b64d8016d380d5985339658 Closes-Bug: #1888037 Related-Bug: #1813725
2020年07月20日 14:18:33 -07:00
# Over time, the format of crypto metadata on disk may change slightly to resolve
# ambiguities. In general, you want to be writing the newest version, but to
# ensure that all writes can still be read during rolling upgrades, there's the
# option to write older formats as well.
# Before upgrading from Swift 2.20.0 or earlier, ensure this is set to 1
# Before upgrading from Swift 2.25.0 or earlier, ensure this is set to at most 2
# After upgrading all proxy servers, set this to 3 (currently the highest version)
# meta_version_to_write = 3
# The value of the ``key_id`` option should be the unique identifier for a
# secret that will be retrieved from the KMIP service. The secret should be an
# AES-256 symmetric key.
# key_id = <unique id of secret to be fetched from the KMIP service>
# The remaining options are used to configure a PyKMIP client and are shown
# below for information. The authoritative definition of these options can be
# found at: https://pykmip.readthedocs.io/en/latest/client.html.
# host = <KMIP server host>
# port = <KMIP server port>
# certfile = /path/to/client/cert.pem
# keyfile = /path/to/client/key.pem
# ca_certs = /path/to/server/cert.pem
# username = <KMIP username>
# password = <KMIP password>