On Thu, 2018-05-17 at 10:33 +0200, Cédric Jeanneret wrote:
>
> On 05/17/2018 10:18 AM, Bogdan Dobrelya wrote:
> > On 5/17/18 9:58 AM, Thierry Carrez wrote:
> > > Jeremy Stanley wrote:
> > > > [...]
> > > > As a community, we're likely to continue to make imbalanced
> > > > trade-offs against relevant security features if we don't move
> > > > forward and declare that some sort of standardized key storage
> > > > solution is a fundamental component on which OpenStack services
> > > > can
> > > > rely. Being able to just assume that you can encrypt volumes in
> > > > Swift, even as a means to further secure a TripleO undercloud,
> > > > would
> > > > be a step in the right direction for security-minded
> > > > deployments.
> > > >
> > > > Unfortunately, I'm unable to find any follow-up summary on the
> > > > mailing list from the aforementioned session, but recollection
> > > > from
> > > > those who were present (I had a schedule conflict at that time)
> > > > was
> > > > that a Castellan-compatible key store would at least be a
> > > > candidate
> > > > for inclusion in our base services list:
> > > >
> > > > https://governance.openstack.org/tc/reference/base-services.htm
> > > > l
> > >
> > > Yes, last time this was discussed, there was lazy consensus that
> > > adding "a Castellan-compatible secret store" would be a good
> > > addition
> > > to the base services list if we wanted to avoid proliferation of
> > > half-baked keystore implementations in various components.
> > >
> > > The two blockers were:
> > >
> > > 1/ castellan had to be made less Barbican-specific, offer at
> > > least one
> > > other secrets store (Vault), and move under Oslo (done)
> >
> > Back to the subject and tripleo underclouds running Barbican, using
> > vault as a backend may be a good option, given that openshift
> > supports
> > [0] it as well for storing k8s secrets, and kubespray does [1] for
> > vanilla k8s deployments, and that we have openshift/k8s-based
> > control
> > plane for openstack on the integration roadmap. So we'll highly
> > likely
> > end up running Barbican/Vault on undercloud anyway.
> >
> > [0]
> > https://blog.openshift.com/managing-secrets-openshift-vault-integra
> > tion/
> > [1]
> > https://github.com/kubernetes-incubator/kubespray/blob/master/docs/
> > vault.md
> >
>
> That just sounds lovely, especially since this allows to converge
> "secure storage" tech between projects.
> On my own, I was considering some secure storage (custodia) in the
> context of the public TLS certificate storage/update/provisioning.
> Having by default a native way to store secrets used by the overcloud
> deploy/life is a really good thing, and will prevent leaks, having
> ardcoded passwords in files and so on (although, yeah, you'll need
> something to access barbican ;)).
>
I think that for consistency sake, we will want to use a Castellan-
compatible back-end in the undercloud, rather than something more
custom like a LUKS encrypted partition or similar.
Right now, that means either castellan -> vault or castellan->
barbican. In the future, it could also mean castellan-> custodia.
If you do use Barbican, you could still use vault as a backend to
Barbican. ie. castellan -> barbican -> vault.
> > >
> > > 2/ some projects (was it Designate ? Octavia ?) were relying on
> > > advanced functions of Barbican not generally found in other
> > > secrets
> > > store, like certificate generation, and so would prefer to depend
> > > on
> > > Barbican itself, which confuses the messaging around the base
> > > service
> > > addition a bit ("any Castellan-supported secret store as long as
> > > it's
> > > Barbican")
> > >
> >
> >
>
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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
