On 04/26/2016 08:28 AM, Guangyu Suo wrote:
Hello, oslo team
For now, some sensitive options like password or token are configured
as plaintext, anyone who has the priviledge to read the configure file
can get the real password, this may be a security problem that can't
be unacceptable for some people.
So the first solution comes to my mind is to encrypt these options
when configuring them and decrypt them when reading them in
oslo.config. This is a bit like apache/openldap did, but the
difference is these softwares do a salt hash to the password, this is
a one-way encryption that can't be decrypted, these softwares can
recognize the hashed value. But if we do this work in oslo.config, for
example the admin_password in keystone_middleware section, we must
feed the keystone with the plaintext password which will be hashed in
keystone to compare with the stored hashed password, thus the encryped
value in oslo.config must be decryped to plaintext. So we should
encrypt these options using symmetrical or unsymmetrical method with a
key, and put the key in a well secured place, and decrypt them using
the same key when reading them.
Of course, this feature should be default closed. Any ideas?
PKI. Each service gets a client certificate that they use, signed by a
selfsigned CA on the controller node, and uses the Tokenless/X509
Mapping in Keystone to identify itself.
Do not try to build a crypto system around passwords. None of us are
qualified to do that.
We should be able to kill explicit service users and use X509 any way.
Kerberos would work, too, for deployments that prefer that form of
Authentication. We can document this, but do not need to implement.
Certmonger can manage the certificates for us.
Anchor can act as the CA for deployments that want something more than
selfsigned, but don't want to go with a full CA.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
