Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-06-21 Thread Zane Bitter 

On 20/06/18 17:59, Adam Harwell wrote:

Looks like I missed this so I'm late to the party, but:

Ade is technically correct, Octavia doesn't explicitly depend on 
Barbican, as we do support castellan generically.


*HOWEVER*: we don't just store and retrieve our own secrets -- we rely 
on loading up user created secrets. This means that for Octavia to work, 
even if we use castellan, we still need some way for users to interact 
with the secret store via an API, and what that means in openstack in 
still Barbican. So I would still say that Barbican is a dependency for 
us logistically, if not technically.


Right, yeah, I'd call that a dependency on Barbican.

There are reportedly, however, other use cases where the keys are 
generated internally that don't depend on Barbican but can benefit from 
Castellan.


It might be a worthwhile exercise to make a list of all of the proposed 
features that have been blocked on this and whether they require user 
interaction with the key store.


For example, internally at GoDaddy we were investigating deploying Vault 
with a custom user-facing API/UI for allowing users to store secrets 
that could be consumed by Octavia with castellan (don't get me started 
on how dumb that is, but it's what we were investigating).
The correct way to do this in an openstack environment is the openstack 
secret store API, which is Barbican.


This is the correct answer, and thank you for being awesome :)

So, while I am personally dealing 
with an example of very painfully avoiding Barbican (which may have been 
a non-issue if Barbican were a base service), I have a tough time 
reconciling not including Barbican itself as a requirement.


On the bright side, getting everyone to deploy either Barbican or Vault 
makes it easier even for the folks who chose Vault to deploy Barbican later.


I don't think we've given up on making Barbican a base service, just 
recognised that it's a longer-term effort whereas this is something we 
can do to start down the path right now.


cheers,
Zane.


    --Adam (rm_work)

On Wed, Jun 20, 2018, 11:37 Jeremy Stanley > wrote:


On 2018-06-06 01:29:49 + (+), Jeremy Stanley wrote:
[...]
 > Seeing no further objections, I give you
 > https://review.openstack.org/572656 for the next step.

That change merged just a few minutes ago, and

https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
now includes:

     A Castellan-compatible key store

     OpenStack components may keep secrets in a key store, using
     Oslo’s Castellan library as an indirection layer. While
     OpenStack provides a Castellan-compatible key store service,
     Barbican, other key store backends are also available for
     Castellan. Note that in the context of the base services set
     Castellan is intended only to provide an interface for services
     to interact with a key store, and it should not be treated as a
     means to proxy API calls from users to that key store. In order
     to reduce unnecessary exposure risks, any user interaction with
     secret material should be left to a dedicated API instead
     (preferably as provided by Barbican).

Thanks to everyone who helped brainstorming/polishing, and here's
looking forward to a ubiquity of default security features and
functionality in future OpenStack releases!
-- 
Jeremy Stanley

__
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




__
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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-06-21 Thread Jeremy Stanley 
On 2018-06-20 16:59:30 -0500 (-0500), Adam Harwell wrote:
> Looks like I missed this so I'm late to the party, but:
> 
> Ade is technically correct, Octavia doesn't explicitly depend on Barbican,
> as we do support castellan generically.
> 
> *HOWEVER*: we don't just store and retrieve our own secrets -- we rely on
> loading up user created secrets. This means that for Octavia to work, even
> if we use castellan, we still need some way for users to interact with the
> secret store via an API, and what that means in openstack in still
> Barbican. So I would still say that Barbican is a dependency for us
> logistically, if not technically.
> 
> For example, internally at GoDaddy we were investigating deploying Vault
> with a custom user-facing API/UI for allowing users to store secrets that
> could be consumed by Octavia with castellan (don't get me started on how
> dumb that is, but it's what we were investigating).
> The correct way to do this in an openstack environment is the openstack
> secret store API, which is Barbican. So, while I am personally dealing with
> an example of very painfully avoiding Barbican (which may have been a
> non-issue if Barbican were a base service), I have a tough time reconciling
> not including Barbican itself as a requirement.
[...]

The past pushback we received from operators and deployers was that
they didn't want to be required to care and feed for yet one more
API service. As a compromise, it was suggested that we at least
provide a guaranteed means for services to handle their own secrets
in a centralized and standardized manner. In practice, the wording
we arrived at is intended to drive projects to strongly recommend
deploying Barbican in cases where operators want to take advantage
of any features of other services which require user interaction
with the key store.

Making a user-facing API service a "required project" from that
perspective is a bigger discussion, in my opinion. I'm in favor of
trying, but to me this piece is the first step in such a direction.
-- 
Jeremy Stanley


signature.asc
Description: PGP 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-06-20 Thread Adam Harwell 
Looks like I missed this so I'm late to the party, but:

Ade is technically correct, Octavia doesn't explicitly depend on Barbican,
as we do support castellan generically.

*HOWEVER*: we don't just store and retrieve our own secrets -- we rely on
loading up user created secrets. This means that for Octavia to work, even
if we use castellan, we still need some way for users to interact with the
secret store via an API, and what that means in openstack in still
Barbican. So I would still say that Barbican is a dependency for us
logistically, if not technically.

For example, internally at GoDaddy we were investigating deploying Vault
with a custom user-facing API/UI for allowing users to store secrets that
could be consumed by Octavia with castellan (don't get me started on how
dumb that is, but it's what we were investigating).
The correct way to do this in an openstack environment is the openstack
secret store API, which is Barbican. So, while I am personally dealing with
an example of very painfully avoiding Barbican (which may have been a
non-issue if Barbican were a base service), I have a tough time reconciling
not including Barbican itself as a requirement.

   --Adam (rm_work)

On Wed, Jun 20, 2018, 11:37 Jeremy Stanley  wrote:

> On 2018-06-06 01:29:49 + (+), Jeremy Stanley wrote:
> [...]
> > Seeing no further objections, I give you
> > https://review.openstack.org/572656 for the next step.
>
> That change merged just a few minutes ago, and
>
> https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
> now includes:
>
> A Castellan-compatible key store
>
> OpenStack components may keep secrets in a key store, using
> Oslo’s Castellan library as an indirection layer. While
> OpenStack provides a Castellan-compatible key store service,
> Barbican, other key store backends are also available for
> Castellan. Note that in the context of the base services set
> Castellan is intended only to provide an interface for services
> to interact with a key store, and it should not be treated as a
> means to proxy API calls from users to that key store. In order
> to reduce unnecessary exposure risks, any user interaction with
> secret material should be left to a dedicated API instead
> (preferably as provided by Barbican).
>
> Thanks to everyone who helped brainstorming/polishing, and here's
> looking forward to a ubiquity of default security features and
> functionality in future OpenStack releases!
> --
> Jeremy Stanley
> __
> 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-06-20 Thread Jeremy Stanley 
On 2018-06-06 01:29:49 + (+), Jeremy Stanley wrote:
[...]
> Seeing no further objections, I give you
> https://review.openstack.org/572656 for the next step.

That change merged just a few minutes ago, and
https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
now includes:

A Castellan-compatible key store

OpenStack components may keep secrets in a key store, using
Oslo’s Castellan library as an indirection layer. While
OpenStack provides a Castellan-compatible key store service,
Barbican, other key store backends are also available for
Castellan. Note that in the context of the base services set
Castellan is intended only to provide an interface for services
to interact with a key store, and it should not be treated as a
means to proxy API calls from users to that key store. In order
to reduce unnecessary exposure risks, any user interaction with
secret material should be left to a dedicated API instead
(preferably as provided by Barbican).

Thanks to everyone who helped brainstorming/polishing, and here's
looking forward to a ubiquity of default security features and
functionality in future OpenStack releases!
-- 
Jeremy Stanley


signature.asc
Description: PGP 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-06-05 Thread Jeremy Stanley 
On 2018-05-31 13:00:47 + (+), Jeremy Stanley wrote:
> On 2018-05-31 10:33:51 +0200 (+0200), Thierry Carrez wrote:
> > Ade Lee wrote:
> > > [...]
> > > So it seems that the two blockers above have been resolved. So is it
> > > time to ad a castellan compatible secret store to the base services?
> > 
> > It's definitely time to start a discussion about it, at least :)
> > 
> > Would you be interested in starting a ML thread about it ? If not, that's
> > probably something I can do :)
> 
> That was, in fact, the entire reason I started this subthread,
> changed the subject and added the [tc] tag. ;)
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html
> 
> I figured I'd let it run through the summit to garner feedback
> before proposing the corresponding Gerrit change.

Seeing no further objections, I give you
https://review.openstack.org/572656 for the next step.
-- 
Jeremy Stanley


signature.asc
Description: PGP 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-31 Thread Jeremy Stanley 
On 2018-05-31 10:33:51 +0200 (+0200), Thierry Carrez wrote:
> Ade Lee wrote:
> > [...]
> > So it seems that the two blockers above have been resolved. So is it
> > time to ad a castellan compatible secret store to the base services?
> 
> It's definitely time to start a discussion about it, at least :)
> 
> Would you be interested in starting a ML thread about it ? If not, that's
> probably something I can do :)

That was, in fact, the entire reason I started this subthread,
changed the subject and added the [tc] tag. ;)

http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html

I figured I'd let it run through the summit to garner feedback
before proposing the corresponding Gerrit change.
-- 
Jeremy Stanley


signature.asc
Description: PGP 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-31 Thread Thierry Carrez 

Ade Lee wrote:

[...]
So it seems that the two blockers above have been resolved. So is it
time to ad a castellan compatible secret store to the base services?


It's definitely time to start a discussion about it, at least :)

Would you be interested in starting a ML thread about it ? If not, 
that's probably something I can do :)


--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-30 Thread Ade Lee 
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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-30 Thread Ade Lee 
On Thu, 2018-05-17 at 09:58 +0200, 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.html
> 
> 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)
> 
> 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")
> 

As far as I know, Octavia no longer depends on barbican specific
functions.  Rather, they use castellan now.

And the current oslo-config work provides secrets through a castellan
backend.

So it seems that the two blockers above have been resolved. So is it
time to ad a castellan compatible secret store to the base services?

Ade   

__
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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-17 Thread Cédric Jeanneret 


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.html
>>
>> 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-integration/
> [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 ;)).

>>
>> 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")
>>
> 
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-17 Thread Bogdan Dobrelya 

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.html


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-integration/
[1] 
https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vault.md




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")





--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

2018-05-17 Thread Thierry Carrez 

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.html


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)


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")


--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

2018-05-16 Thread Jeremy Stanley 
On 2018-05-16 17:42:09 + (+), Jeremy Stanley wrote:
[...]
> 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
[...]

As Jim Rollenhagen pointed out in #openstack-tc, I was probably
thinking of the earlier Pike PTG session the Architecture WG held,
summarized at:

http://lists.openstack.org/pipermail/openstack-dev/2017-February/113016.html

Ensuing discussion yielded that there was no good reason to rename a
library even if the Oslo team was going to officially adopt it
(which for castellan they subsequently did in March 2017).
-- 
Jeremy Stanley


signature.asc
Description: PGP 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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

2018-05-16 Thread Doug Hellmann 
Excerpts from Jeremy Stanley's message of 2018-05-16 17:42:09 +:
> On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote:
> > On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote:
> > > As part of the work from the Security Squad, we added the
> > > ability for the containerized undercloud to encrypt the
> > > overcloud plans. This is done by enabling Swift's encrypted
> > > volumes, which require barbican. Right now it's turned off, but
> > > I would like to enable it by default [1]. What do you folks
> > > think?
> > 
> > I like the idea, but I'm a bit skeptical about adding a new
> > service to already quite bloated undercloud. Why is barbican a
> > hard requirement here?
> [...]
> 
> This exchange has given me pause to reflect on discussions we were
> having one year ago (leading up to and at the Forum in Boston).
> 
> https://www.openstack.org/summit/boston-2017/summit-schedule/events/18736/key-management-developeroperatorcommunity-coordination
> 
> https://etherpad.openstack.org/p/BOS-forum-key-management
> 
> 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.html
> 
> So a year has passed... where are we with this? Is it still
> something we want to do (I think so, do others)? What are the next
> steps so this doesn't come up again and again?

It seems like we should add "some form of key manager" to the base
service lists, shouldn't we? And then we would encourage projects to use
castellan to talk to it. Unless we want to try to pick a single key
manager, which feels like a much longer sort of conversation.

Doug

__
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-dev] [tripleo] [barbican] [tc] key store in base services (was: Encrypted swift volumes by default in the undercloud)

2018-05-16 Thread Jeremy Stanley 
On 2018-05-16 13:16:09 +0200 (+0200), Dmitry Tantsur wrote:
> On 05/15/2018 09:19 PM, Juan Antonio Osorio wrote:
> > As part of the work from the Security Squad, we added the
> > ability for the containerized undercloud to encrypt the
> > overcloud plans. This is done by enabling Swift's encrypted
> > volumes, which require barbican. Right now it's turned off, but
> > I would like to enable it by default [1]. What do you folks
> > think?
> 
> I like the idea, but I'm a bit skeptical about adding a new
> service to already quite bloated undercloud. Why is barbican a
> hard requirement here?
[...]

This exchange has given me pause to reflect on discussions we were
having one year ago (leading up to and at the Forum in Boston).

https://www.openstack.org/summit/boston-2017/summit-schedule/events/18736/key-management-developeroperatorcommunity-coordination

https://etherpad.openstack.org/p/BOS-forum-key-management

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.html

So a year has passed... where are we with this? Is it still
something we want to do (I think so, do others)? What are the next
steps so this doesn't come up again and again?
-- 
Jeremy Stanley


signature.asc
Description: PGP 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