This does seem to make a lot of sense. Basically what we will get is an improved lowest common denominator when it comes to intra-node TLS. This probably also fits in nicely with work others in OpenStack Security have recently discussed regarding the creation of a super-lightweight CA.
The only potential security drawback is that we are introducing a new asset to protect. If we create the tools that enable a deployer to easily create and administer a lightweight CA, that should add significant value to OpenStack, especially for smaller organizations that don't have experience running a CA. I'd be curious to hear what the more crypto/CA focused members of OpenStack Security have to say as well. Thanks, -Travis >Hello there, > >I've been researching some additional ways to secure openstack-ansible >deployments and I backed myself into a corner with secure log >transport. The rsyslog client requires a trusted CA certificate to be >able to send encrypted logs to rsyslog servers. That's not a problem >if users bring their own certificates, but it does become a problem if >we use the self-signed certificates that we're creating within the >various roles. > >I'm wondering if we could create a role that creates a CA on the >deployment host and then uses that CA to issue certificates for various >services *if* user doesn't specify that they want to bring their own >certificates. We could build the CA very early in the installation >process and then use it to sign certificates for each individual >service. That would allow to have some additional trust in >environments where deployers don't choose to bring their own >certificates. > >Does this approach make sense?
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ 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
