On Mon, May 2, 2016 at 11:32 AM, Adam Young <ayo...@redhat.com> wrote:
> 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. > > ++ Rule 1 of crypto - don't roll your own system. > We should be able to kill explicit service users and use X509 any way. > > ++ We should be moving towards token-less auth for service users where possible. This doesn't mitigate the need to cert/key manage properly (NSS? devops-y things, etc) > Kerberos would work, too, for deployments that prefer that form of > Authentication. We can document this, but do not need to implement. > > Never hurts to have alternatives. > 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. > > I'd be in favor of anchor being the default (devstack? gate? "best practices") choice for 'service users' over the full CA, but in either case as long as we have an easy-to-use-low-barrier-to-entry-well-formed-system, we're on the right path. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 > >
__________________________________________________________________________ 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
