To ease upgrades from Mitaka to Newton, we are introducing the
concept of a null key to keystone's implementation of credential
encryption. The null key can be assumed by keystone if no other
keys exists in the configured `CONF [credential] key_repository`
and it is a known value, so it doesn't need to be orchestrated
across nodes in multi-node deployments.
This allows an operator to upgrade from Mitaka to Newton without
having to setup a credential key repository beforehand. It is
strongly recommended that deployers configure their key_repository
and migrate off of the null key as soon as possible. Since the null
key is a known value, it is no more secure than storing secrets in
plain text. It is only here to ease the upgrade process for
deployers.
Reviewed: https:/ /review. openstack. org/366831 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=e9b64378e64 e0308a07242ddc3 8736cc3abd4c2a
Committed: https:/
Submitter: Jenkins
Branch: master
commit e9b64378e64e030 8a07242ddc38736 cc3abd4c2a
Author: Lance Bragstad <email address hidden>
Date: Wed Sep 7 14:53:44 2016 +0000
Introduce null key for credential encryption
To ease upgrades from Mitaka to Newton, we are introducing the
concept of a null key to keystone's implementation of credential
encryption. The null key can be assumed by keystone if no other
keys exists in the configured `CONF [credential] key_repository`
and it is a known value, so it doesn't need to be orchestrated
across nodes in multi-node deployments.
This allows an operator to upgrade from Mitaka to Newton without
having to setup a credential key repository beforehand. It is
strongly recommended that deployers configure their key_repository
and migrate off of the null key as soon as possible. Since the null
key is a known value, it is no more secure than storing secrets in
plain text. It is only here to ease the upgrade process for
deployers.
Change-Id: I6cca7e40ce36a8 a24dc73f92b2248 7998da6a1ae
Related-Bug: 1619758