[openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

Luke Hinds lhinds at redhat.com
Sat Nov 19 22:35:47 UTC 2016


On Fri, Nov 18, 2016 at 4:14 PM, Dean Troyer <dtroyer at gmail.com> wrote:

> > -----Original Message-----
> > From: Luke Hinds <lhinds at redhat.com>
> [...]
> >> for non security related functions, but when it comes to government
> >> compliance and running OpenStack on public clouds (and even private for
> the
> >> Telcos / NFV), not meeting FIPS will in some cases block production
> getting
> >> a green light, or at least make it a big challenge to push through.
>
> Are there any know cases of this happening?  If so, can those be
> publicly documented to quantify how much this issue is hurting
> deployments?
>
>
>
I don't have any that I could share publicly at the moment, but I will dig
around.

I expect the FIPS 140-2 requirement will be more frequently requested for
the telecommunications based NFV deployments, which as we all see, are
undergoing a groundswell in OpenStack, with many networks expected to go
into production over the next five years. Security compliance tends to be
more strictly enforced in Telco as the networks are seen as a critical
infrastructure.


> On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco <sigmavirus24 at gmail.com>
> wrote:
> > Also, instead of creating bugs, I would suggest instead that we try to
> make this into a community goal. We would work with the TC and for P or Q,
> make it a goal to start migrating off of MD5 and have a goal for a cycle or
> two later to completely remove reliance on MD5.
> >
> > Doing this piecemeal via bugs will not be efficient and we'll need
> community buy-in.
>
>
If that is the more pragmatic approach and there is TC buy in, then let's
go ahead. Whatever means is most effective in getting it done.

At some point, I think we will need a tag to return a set of bugs to gauge
progress, but I agree the consensus needs to be in place, more then a bug
list.


We would also need to get a reasonable scoping of the issue (which
> projects, how many instances, etc) to help decide if this is an
> achievable goal (in the sense of the 'community goals').
>
> As you noted, this will not be easy for Swift or Glance (others?), but
> if the impact to deployers can be quantified it makes it easier to
> spend energy here.
>
>
I can collate figures on how many instances there are, on which projects
etc.

The part where I am green is how this would be taken forward to gain
community consensus or TC approval.

dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161119/80e8071e/attachment.html>


More information about the OpenStack-dev mailing list