Re: [openstack-dev] [kolla][tc] [security] threat analysis, tags, and the road ahead

[Clark, Robert Graham]

On 12/04/2016 18:37, "Jeremy Stanley"  wrote:



>On 2016-04-01 15:50:57 + (+), Hayes, Graham wrote:
>> If a team has already done a TA (e.g. as part of an internal
>> product TA) (and produced all the documentation) would this meet
>> the requirements?
>> 
>> I ask, as Designate looks like it meets nearly  all the current
>> requirements - the only outstanding question in my mind was the
>> Threat Analysis
>
>Seems fine to me, though in the interest of openness that
>documentation should probably be licensed such that it can be
>published somewhere for the whole community to read (once any
>glaring deficiencies are addressed anyway).
>-- 
>Jeremy Stanley

In some cases this may be feasible, in others less so. TA in general
tends to be implementation specific which is why, when discussing how
the Security Project would be performing TA work within OpenStack we
decided that it should be reflective of a best-practice deployment for
whatever project was being evaluated.[1][2]

There are two OpenStack vendors I know of that do in depth functional
threat analysis on OpenStack projects. I have been highly involved in
the development of TA at HPE and various colleagues in the Security
project have been involved with the TA process at Rackspace. When
evaluating our documentation sets together at the mid-cycle[2] it was
felt that in both cases, some degree of "normalization" would need to be
performed before either of us would be ready to share these documents
externally.

-Rob [Security]

[1] 
https://openstack-security.github.io/collaboration/2016/01/16/threat-analysis.html
[2] https://openstack-security.github.io/threatanalysis/2016/02/07/anchorTA.html
[3] 
https://openstack-security.github.io/mid-cycle/2016/01/15/mitaka-midcycle.html



__
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] [Openstack-security] [Security]abandoned OSSNs?

[Clark, Robert Graham]

Thanks Matt, Michael,

To start with, lets look quickly at the more recent OSSNs that are marked as 
work in progress, namely 63,64,65 and 66 – these should all be published within 
a week or so.

Looking further back we have the more difficult OSSNs 50 and 51, I’m not 100% 
sure what the blockers are on these.  I believe 
https://wiki.openstack.org/wiki/OSSN/OSSN-0056 may supersede OSSN-0051 and is 
rooted in bug https://bugs.launchpad.net/ossn/+bug/1435530 - it looks to me 
like OSSN-0056 was written during a mid-cycle and could be the right one.

I’m struggling to work out the story behind OSSN-0050 – I’m adding Nathan 
Kinder who might be able to shed more light on this.

-Rob



From: Michael Xin [mailto:michael@rackspace.com]
Sent: 11 April 2016 15:28
To: Matt Fischer; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

Matt:
Thanks for asking this. I forwarded this email to the new email list so that 
folks with better knowledge can answer this.


Thanks and have a great day.

Yours,
Michael


-
Michael Xin | Manager, Security Engineering - US
Product Security  |Rackspace Hosting
Office #: 501-7341   or  210-312-7341
Mobile #: 210-284-8674
5000 Walzem Road, San Antonio, Tx 78218

Experience fanatical support

From: Matt Fischer >
Date: Monday, April 11, 2016 at 9:19 AM
To: 
"openstack-secur...@lists.openstack.org"
 
>
Subject: [Openstack-security] abandoned OSSNs?

Some folks from our security team here asked me to ensure them that our 
services were patched for all the OSSNs that are listed here: 
https://wiki.openstack.org/wiki/Security_Notes

Most of these are straight-forward, but there are some OSSNs that have been 
allocated an ID but then abandoned. There is no detailed wiki page and my best 
google efforts lead me to a possible IRC mention and maybe an abandoned review. 
The two specifically are OSSN-50/51.

So what am I to do with an "abandoned" OSSN? Has it been decided that there is 
no issue anymore? These are pretty old if I look at the dates framing the other 
OSSNs (49/52), so I assume they aren't urgent. Can we ignore these? They sound 
somewhat scary, for example, "keystonemiddleware can allow access after token 
revocation" but I have no means to say whether it affects us or how we can 
mitigate without more info.

Thoughts?
__
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] [Security][Keystone] OSSN-0064 Draft. Request for review

[Clark, Robert Graham]

Hi Guys,

OSSN-0064 is in review and requires some Keystone love.

https://review.openstack.org/#/c/300091/

In relation to:
https://bugs.launchpad.net/ossn/+bug/1545789

Cheers
-Rob

__
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] [Security] Standing agenda for security IRC meetings

[Clark, Robert Graham]

Hi all,

As per yesterday’s meeting[1], it seems more sensible to create a standing 
agenda rather than using a new ether pad for each meeting.

The standing agenda is available here: 
https://etherpad.openstack.org/p/security-agenda

Please bookmark this and add topics you’d like to discuss before each weekly 
meeting.

Cheers
-Rob

[1]http://eavesdrop.openstack.org/meetings/security/2016/security.2016-04-07-17.00.log.html



__
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] [Security][Barbican] BYOK

[Clark, Robert Graham]

Hi All,

We’ve had lots of discussion about BYOK and most of it has lead to “lets 
discuss it at the summit”.

I’ve got some time for this in the security schedule, I’m checking – is there 
some other place where this is already tabled to be discussed?

-Rob
__
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] [kolla][tc] [security] threat analysis, tags, and the road ahead

[Clark, Robert Graham]

Thanks Steve, Mike,

We’ve had a lot more traction with this latest incarnation of TA. I’m 
very much looking forward to working through the process with the
wider community.

-Rob



On 31/03/2016 20:44, "Steven Dake (stdake)"  wrote:

>Including tc and kolla
>
>Michael,
>
>Sounds good.  I'll get the governance changes rolling for debate at the
>next TC meeting.
>
>Note I added this cross project topic for discussion Tuesday at summit
>(last item in the list)
>https://etherpad.openstack.org/p/newton-cross-project-sessions
>
>Regards,
>-steve
>
>On 3/31/16, 12:15 PM, "michael mccune"  wrote:
>
>>hey all,
>>
>>at the most recent ossp meeting[1], there was some extended discussion
>>about threat analysis and the work that is being done to push this
>>forward.
>>
>>in this discussion, there were several topics brought up around the
>>process for doing these analyses on current projects and how the ossp
>>should proceed especially with respect to the "vulnerability:managed"
>>tag[2].
>>
>>as for the threat analysis process, there are still several questions
>>which need to be answered:
>>
>>* what is the process for performing an analysis
>>
>>* how will an analysis be formally recognized and approved
>>
>>* who will be doing these analyses
>>
>>* does it make sense to keep the analysis process strictly limited to
>>the vmt
>>
>>* how to address commonalities and differences between a developer
>>oriented analysis and a deployer oriented analysis
>>
>>these questions all feed into another related topic, which is the
>>proposed initial threat analysis for kolla which has been suggested to
>>start at the upcoming austin summit.
>>
>>i wanted to capture some of the discussion happening around this topic,
>>and continue the ball rolling as to how we will solve these questions as
>>we head to summit.
>>
>>one of the big questions seems to be who should be doing these analysis,
>>especially given that the ossp has not formally codified the practice
>>yet, and the complexity involved. although currently the
>>vulnerability:managed tag suggests that a third party review should be
>>done, this may prove difficult to scale in practice. i feel that it
>>would be in the best interests of the wider openstack community if the
>>ossp works towards creating instructional material that can empower the
>>project teams to start their own analyses.
>>
>>ultimately, having a third-party review of a project is worthy goal, but
>>this has to be tempered with the reality that a single team will not be
>>able to scale out and provide thorough analyses for all projects. to
>>that extent, the ossp should work, initially, to help a few teams get
>>these analyses completed and in the process create a set of useful tools
>>(docs, guides, diagrams, foil-hat wearing pamphlets) to help further the
>>effort.
>>
>>i would like to propose that the threat analysis portion of the
>>vulnerability:managed tag be modified with the goal of having the
>>project teams create their own analyses, with an extended third-party
>>review to be performed afterwards. in this respect, the scale issue can
>>be addressed, as well as the issue of project domain knowledge. it makes
>>much more sense to me to have the project team creating the initial work
>>here as they will know the areas, and architectures, that will need the
>>most attention.
>>
>>as the ossp build better tools for generating these analyses they will
>>be in a much better position to guide project teams in their initial
>>analyses, with the ultimate goal of having the ossp, and/or vmt, perform
>>the third-party audit for application of the tag. i have a feeling we
>>will also discover much overlap between the developer and deployer
>>oriented analyses, and these overlaps will help to strengthen the
>>process for all involved.
>>
>>finally, the austin summit, and proposed kolla review, provide a great
>>opportunity for the ossp to put "rubber on the road" with respect to
>>this process. although a full analysis may not be accomplished during
>>the summit, we can definitely achieve the goal of defining this process
>>much better and creating more guidance for all projects that wish to
>>follow this path, as well as having kolla solidly on the way to having a
>>full threat analysis ready for third-party review.
>>
>>thoughts?
>>
>>
>>regards,
>>mike
>>
>>
>>[1]: 
>>http://eavesdrop.openstack.org/meetings/security/2016/security.2016-03-31-
>>17.00.log.txt
>>
>>[2]: 
>>http://governance.openstack.org/reference/tags/vulnerability_managed.html
>>
>>[3]: https://review.openstack.org/#/c/220712/
>>
>>__
>>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 

[openstack-dev] [Security] Newton Design Summit Etherpad

[Clark, Robert Graham]

Hi Guys,

Please take a few minutes to add ideas to 
https://etherpad.openstack.org/p/security-newton-summit-brainstorm

These don’t have to be things you want to lead, just things you think would be 
valuable

-Rob
__
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] [magnum] High Availability

[Clark, Robert Graham]

At the risk of muddying the waters further, I recently chatted with some of you 
about Anchor, it's an ephemeral PKI system setup to provide private community 
PKI - certificate services for internal systems, a lot like k8 pods.

An overview of why revocation doesn't work very well in many cases and how 
ephemeral PKI helps: 
https://openstack-security.github.io/tooling/2016/01/20/ephemeral-pki.html

First half of a threat analysis on Anchor, the Security Project's 
implementation of ephemeral PKI: 
https://openstack-security.github.io/threatanalysis/2016/02/07/anchorTA.html

This might not solve your problem, it's certainly not a direct drop in for 
Barbican (and it never will be) but if your primary concern is Certificate 
Management for internal systems (not presenting certificates over the edge of 
the cloud) you might find some of it's properties valuable. Not least, it's 
trivial to HA being stateless and it's trivial to deploy being a single Pecan 
service.

There's a reasonably complete deck on Anchor here:
https://docs.google.com/presentation/d/1HDyEiSA5zp6HNdDZcRAYMT5GtxqkHrxbrqDRzITuSTc/edit?usp=sharing

And of course, code over here:
http://git.openstack.org/cgit/openstack/anchor

Cheers
-Rob

> -Original Message-
> From: Maish Saidel-Keesing [mailto:mais...@maishsk.com]
> Sent: 19 March 2016 18:10
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] High Availability
> 
> Forgive me for the top post and also for asking the obvious (with my
> Operator hat on)
> 
> Relying on an external service for certificate store - is the best
> option - assuming of course that the certificate store is actually also
> highly available.
> 
> Is that the case today with Barbican?
> 
> According to the architecture docs [1] I see that they are using a
> relational database. MySQL? PostgreSQL? Does that now mean we have an
> additional database to maintain, backup, provide HA for as an Operator?
> 
> The only real reference I can see to anything remotely HA is this [2]
> and this [3]
> 
> An overall solution is highly available *only* if all of the parts it
> relies are also highly available as well.
> 
> 
> [1]
> http://docs.openstack.org/developer/barbican/contribute/architecture.html#overall-architecture
> [2] https://github.com/cloudkeep-ops/barbican-vagrant-zero
> [3] http://lists.openstack.org/pipermail/openstack/2014-March/006100.html
> 
> Some food for thought
> 
> --
> Best Regards,
> Maish Saidel-Keesing
> 
> 
> On 03/18/16 17:18, Hongbin Lu wrote:
> > Douglas,
> >
> > I am not opposed to adopt Barbican in Magnum (In fact, we already adopted 
> > Barbican). What I am opposed to is a Barbican lock-in, which
> already has a negative impact on Magnum adoption based on our feedback. I 
> also want to see an increase of Barbican adoption in the
> future, and all our users have Barbican installed in their clouds. If that 
> happens, I have no problem to have a hard dependency on Barbican.
> >
> > Best regards,
> > Hongbin
> >
> > -Original Message-
> > From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com]
> > Sent: March-18-16 9:45 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [magnum] High Availability
> >
> > Hongbin,
> >
> > I think Adrian makes some excellent points regarding the adoption of 
> > Barbican.  As the PTL for Barbican, it's frustrating to me to
> constantly hear from other projects that securing their sensitive data is a 
> requirement but then turn around and say that deploying Barbican
> is a problem.
> >
> > I guess I'm having a hard time understanding the operator persona that is 
> > willing to deploy new services with security features but
> unwilling to also deploy the service that is meant to secure sensitive data 
> across all of OpenStack.
> >
> > I understand one barrier to entry for Barbican is the high cost of Hardware 
> > Security Modules, which we recommend as the best option for
> the Storage and Crypto backends for Barbican.  But there are also other 
> options for securing Barbican using open source software like
> DogTag or SoftHSM.
> >
> > I also expect Barbican adoption to increase in the future, and I was hoping 
> > that Magnum would help drive that adoption.  There are also
> other projects that are actively developing security features like Swift 
> Encryption, and DNSSEC support in Desginate.  Eventually these
> features will also require Barbican, so I agree with Adrian that we as a 
> community should be encouraging deployers to adopt the best
> security practices.
> >
> > Regarding the Keystone solution, I'd like to hear the Keystone team's 
> > feadback on that.  It definitely sounds to me like you're trying to put
> a square peg in a round hole.
> >
> > - Doug
> >
> > On 3/17/16 8:45 PM, Hongbin Lu wrote:
> >> Thanks Adrian,
> >>
> >>
> >>
> >> I think the Keystone approach will work. For others, please speak up
> >> if it doesn't work for you.
> 

Re: [openstack-dev] [magnum] High Availability

[Clark, Robert Graham]

I thought that a big part of the use case with Magnum + Barbican was 
Certificate management for Bays?

-Rob

From: "Dave McCowan (dmccowan)"
Reply-To: OpenStack List
Date: Saturday, 19 March 2016 14:56
To: OpenStack List
Subject: Re: [openstack-dev] [magnum] High Availability


The most basic requirement here for Magnum is that it needs a safe place to 
store credentials.  A safe place can not be provided by just a library or even 
by just a daemon.  Secure storage is provided by either hardware solution (an 
HSM) or a software solution (SoftHSM, DogTag, IPA, IdM).  A project should give 
a variety of secure storage options to the user.

On this, we have competing requirements.  Devs need a turnkey option for easy 
testing locally or in the gate.  Users kicking the tires want a realistic 
solution they try out easily with DevStack.  Operators who already have secure 
storage deployed for their cloud want an option that plugs into their existing 
HSMs.

Any roll-your-own option is not going to meet all of these requirements.

A good example, that does meet all of these requirements, is the key manager 
implementation in Nova and Cinder. [1] [2]

Nova and Cinder work together to provide volume encryption, and like Magnum, 
have a need to store and share keys securely.  Using a plugin architecture, and 
the Barbican API, they implement a variety of key storage options:
- Fixed key allows for insecure stand alone operation, running only Nova and 
Cinder
- Barbican with static key, allows for easy deployment that can be started 
within DevStack by few lines of config.
- Barbican with a secure backend, allows for production grade secure storage of 
keys that has been tested on a variety of HSMs and software options.

Barbican's adoption is growing.  Nova, Cinder, Neutron LBaaS, Sahara, and 
Magnum all have implementations using Barbican.  Swift and DNSSec also have use 
cases.  There are both RPM and Debian packages available for Barbican.  There 
are (at least tech preview)  versions of puppet modules, Ansible playbooks, and 
DevStack plugins to deploy Barbican.

In summary, I think using Barbican absorbs the complexity of doing secure 
storage correctly.  It gives operators production grade secure storage options, 
while giving devs easier options.

--Dave McCowan

[1] https://github.com/openstack/nova/tree/master/nova/keymgr
[2] https://github.com/openstack/cinder/tree/master/cinder/keymgr

From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, March 18, 2016 at 10:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] High Availability

OK. If using Keystone is not acceptable, I am going to propose a new approach:

· Store data in Magnum DB

· Encrypt data before writing it to DB

· Decrypt data after loading it from DB

· Have the encryption/decryption key stored in config file

· Use encryption/decryption algorithm provided by a library

The approach above is the exact approach used by Heat to protect hidden 
parameters [1]. Compared to the Barbican option, this approach is much lighter 
and simpler, and provides a basic level of data protection. This option is a 
good supplement to the Barbican option, which is heavy but provides advanced 
level of protection. It will fit into the use cases that users don’t want to 
install Barbican but want a basic protection.

If you disagree, I would request you to justify why this approach works for 
Heat but not for Magnum. Also, I also wonder if Heat has a plan to set a hard 
dependency on Barbican for just protecting the hidden parameters.

If you don’t like code duplication between Magnum and Heat, I would suggest to 
move the implementation to a oslo library to make it DRY. Thoughts?

[1] 
https://specs.openstack.org/openstack/heat-specs/specs/juno/encrypt-hidden-parameters.html

Best regards,
Hongbin

From: David Stanek [mailto:dsta...@dstanek.com]
Sent: March-18-16 4:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability


On Fri, Mar 18, 2016 at 4:03 PM Douglas Mendizábal 
> 
wrote:
[snip]
>
> Regarding the Keystone solution, I'd like to hear the Keystone team's 
> feadback on that.  It definitely sounds to me like you're trying to put a 
> square peg in a round hole.
>

I believe that using Keystone for this is a mistake. As mentioned in the 
blueprint, Keystone is not encrypting the data so magnum would be on the hook 
to do it. So that means that if security is a requirement you'd have to 
duplicate more than just code. magnum would start having a larger 

[openstack-dev] [Security] PTL Candidacy

[Clark, Robert Graham]

I'm announcing my candidacy for PTL of the Security project during the
Newton release cycle.

As one of the founders of the Security project I believe I have a strong
base from which to continue developing and enhancing security within
OpenStack.

The security project has taken great strides during this release cycle.
In future we will deliver on stronger security controls, foster more
security innovations and deliver a comprehensive threat analysis
process.

https://review.openstack.org/292538

-Rob

__
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] [Security] IRC Meeting Agenda

[Clark, Robert Graham]

https://etherpad.openstack.org/p/security-20160225-agenda

Cheers
-Rob

__
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] [all] A proposal to separate the design summit

[Clark, Robert Graham]

+1 For security too, this exactly mirrors our experience.

From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: 24 February 2016 12:55
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] A proposal to separate the design summit



On 22 February 2016 at 23:11, Devananda van der Veen 
> wrote:
On 02/22/2016 09:45 AM, Thierry Carrez wrote:

The split should ideally reduce the needs to organize separate in-person 
mid-cycle events. If some are still needed, the main conference venue and time 
could easily be used to provide space for such midcycle events (given that it 
would end up happening in the middle of the cycle).

If this "extra midcycle" is sanctioned by the foundation, even if optional, I'm 
concerned that it would grow until developer attendance is expected again. That 
said, I can appreciate the need to keep the option open for now. Perhaps if the 
Conference organizers include a hack-space and allow developers to 
self-organize if present, it will avoid the draw that a formal midcycle has?

The cinder mid-cycle is, by far, out most productive part of the cycle, and 
this has been true for two cycles now. The midcycle is already much, much 
cheaper to attend than the foundation events, and I think the bulk of the 
productivity comes from the fact that all of the people are totally focused on 
one thing - there's no running out to do something else, little scheduling 
around other commitments (except remote attendees) and plenty of opportunity to 
circle back around to things. The massive progress we made at the Cinder 
midcycle only happened because we came back to it I think four times - the kind 
of thinking and communication needed often doesn't fit into slots and sessions, 
and really needs the bandwidth of face to face time.
I now think the cinder mid-cycle is more valuable for many devs, and much 
cheaper, than the foundation events. I don't see that this proposal will 
actually increase that value at all.

--
Duncan Thomas
__
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] [magnum] Nesting /containers resource under /bays

[Clark, Robert Graham]

+1

Doing this, and doing this well, provides critical functionality to OpenStack 
while keeping said functionality reasonably decoupled from the COE API vagaries 
that would inevitably encumber a solution that sought to provide ‘one api to 
control them all’.

-Rob

From: Mike Metral
Reply-To: OpenStack List
Date: Saturday, 16 January 2016 02:24
To: OpenStack List
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

The requirements that running a fully containerized application optimally & 
effectively requires the usage of a dedicated COE tool such as Swarm, 
Kubernetes or Marathon+Mesos.

OpenStack is better suited for managing the underlying infrastructure.

Mike Metral
Product Architect – Private Cloud R
email: mike.met...@rackspace.com
cell: +1-305-282-7606

From: Hongbin Lu
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, January 15, 2016 at 8:02 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

A reason is the container abstraction brings containers to OpenStack: Keystone 
for authentication, Heat for orchestration, Horizon for UI, etc.

From: Kyle Kelley [mailto:rgb...@gmail.com]
Sent: January-15-16 10:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

What are the reasons for keeping /containers?

On Fri, Jan 15, 2016 at 9:14 PM, Hongbin Lu 
> wrote:
Disagree.

If the container managing part is removed, Magnum is just a COE deployment 
tool. This is really a scope-mismatch IMO. The middle ground I can see is to 
have a flag that allows operators to turned off the container managing part. If 
it is turned off, COEs are not managed by Magnum and requests sent to the 
/container endpoint will return a reasonable error code. Thoughts?

Best regards,
Hongbin

From: Mike Metral 
[mailto:mike.met...@rackspace.com]
Sent: January-15-16 6:24 PM
To: openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

I too believe that the /containers endpoint is obstructive to the overall goal 
of Magnum.

IMO, Magnum’s scope should only be concerned with:

  1.  Provisioning the underlying infrastructure required by the Container 
Orchestration Engine (COE) and
  2.  Instantiating the COE itself on top of said infrastructure from step #1.
Anything further regarding Magnum interfacing or interacting with containers 
starts to get into a gray area that could easily evolve into:

  *   Potential race conditions between Magnum and the designated COE and
  *   Would create design & implementation overhead and debt that could bite us 
in the long run seeing how all COE’s operate & are based off various different 
paradigms in terms of describing & managing containers, and this divergence 
will only continue to grow with time.
  *   Not to mention, the recreation of functionality around managing 
containers in Magnum seems redundant in nature as this is the very reason to 
want to use a COE in the first place – because it’s a more suited tool for the 
task
If there is low-hanging fruit in terms of common functionality across all 
COE’s, then those generic capabilities could be abstracted and integrated into 
Magnum, but these have to be carefully examined beforehand to ensure true 
parity exists for the capability across all COE’s.

However, I still worry that going down this route toes the line that Magnum 
should and could be a part of the managing container story to some degree – 
which again should be the sole responsibility of the COE, not Magnum.

I’m in favor of doing away with the /containers endpoint – continuing with it 
just looks like a snowball of scope-mismatch and management issues just waiting 
to happen.

Mike Metral
Product Architect – Private Cloud R - Rackspace

From: Hongbin Lu >
Sent: Thursday, January 14, 2016 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

In short, the container IDs assigned by Magnum are independent of the container 
IDs assigned by Docker daemon. Magnum do the IDs mapping before doing a native 
API call. In particular, here is how it works.

If users create a container through Magnum endpoint, Magnum will do the 
followings:
1.   Generate a uuid (if not provided).
2.   Call Docker Swarm API to create a container, with its hostname equal 
to the generated uuid.
3.   Persist container to DB with the generated uuid.

If users perform an operation on an existing 

Re: [openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

[Clark, Robert Graham]

I’m pretty new to openstack-ansible-security but based on my use cases which 
are as much
About using this for verification as they are for building secure boxes my 
preference 
would be 3) Use an Ansible callback plugin to catch these and print them at the 
end of the
playbook run

-Rob





On 13/01/2016 09:10, "Major Hayden"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Hey there,
>
>After presenting openstack-ansible-security at the Security Project Mid-Cycle 
>meeting yesterday, the question came up around how to handle situations where 
>automation might cause problems.
>
>For example, the STIG requires[1] that all system accounts other than root are 
>locked.  This could be dangerous on a running production system as Ubuntu has 
>non-root accounts that are not locked.  At the moment, the playbook does a 
>hard stop (using the fail module) when this check fails[2].  Although that can 
>be skipped with --skip-tag, it can be a little annoying if you have automation 
>that depends on the playbook running without stopping.
>
>Is there a good alternative for this?  I've found a few options:
>
>  1) Leave it as-is and do a hard stop on these tasks
>  2) Print a warning to the console but let the playbook continue
>  3) Use an Ansible callback plugin to catch these and print them at the end 
> of the playbook run
>
>Thanks in advance for any advice!
>
>[1] 
>https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2015-05-26/finding/V-38496
>[2] 
>https://github.com/openstack/openstack-ansible-security/blob/master/tasks/auth.yml#L60-L87
>
>- --
>Major Hayden
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQIcBAEBCAAGBQJWlmjbAAoJEHNwUeDBAR+x7zAP/RfGnihciZV0m7Jf+hVKSrzf
>PEc4gauKRA1mZEFdgX4Ib137Vrztu9p1mPB29bRx9GN8aMcY2TtRwrR1QKmUOHX9
>gtrjif9m5XgCM0ja/DMbj82j7pPpIQC5Tby0+CIhX27ZdgGxBpo/9UOj1Dns39Mg
>DzOdNGkGVO6ngmBKdqKetjkT+i0wSKXGQyS341PvyJDy77JCRaGFKc+jRnJWTdVc
>Tpdkc+TL5Rv92gMkMlLnW6txHmtPEJDKjgndhrzWExhY6CLn6XogRMTdZ/1fMP2Y
>x02S4s0VehuNF/9L5nmZ+lBS7HNhtiiSC6KGIo/0X7rZVo9VJ4KNjVaXGQ7clbxS
>sDrqO9uXl98n4S7H44jzBiukYO8MtXVf9djQwujN5A5oN+d1r+sCDDLhxlsLDMVN
>fMlj2LItNREzKe+ZFWBuEkl6GLAO3y0TQPRWYdc3L8PhiwqVJiJ0+WefYO2PNcZe
>Csik3IHCn+jdIq1WdsPQXDEYhAHL1Y1OqEMoBnte/FHeq1BmnojXxuVNtrY1EKtL
>APGGrUbhUWLtZ6v6ke3OT83BSd1FFmLLe/0MlIJ5LYZZZFR/bHgxuEiHcYNr6Fm1
>Dnlrg0NNeeQgClABcB5wK2T8lbDahhxp6Nq7F3MTirnIVYHGo7CYa7g5Gw2b7BMu
>qWWgC8FnH0FzwE7P1LSj
>=wi7P
>-END 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
__
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] [Security] Cancelling the weekly IRC meeting for thanks giving

[Clark, Robert Graham]

Hi all,

As the vast majority of the Security Project members are US based we are 
cancelling the IRC meeting tomorrow.

I’ll send out an ether pad agenda early next week and we can catch up then!

Kind Regards
-Rob
__
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] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

[Clark, Robert Graham]

> -Original Message-
> From: Adam Young [mailto:ayo...@redhat.com]
> Sent: 02 November 2015 20:54
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-ansible][security] Creating a CA for 
> openstack-ansible deployments?
> 
> On 10/26/2015 02:38 PM, Major Hayden wrote:
> > 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* a 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?
> >
> > --
> > Major Hayden
> >
> > __
> > 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
> 
> FreeIPA has a Dogtag server that can be your full CA.  I would recommend
> not rolling our own.
> 
> We have a playbook that does this here:
> https://github.com/admiyo/rippowam  specifically in the
> https://github.com/admiyo/rippowam/tree/master/roles/ipaserver  role
> 

Fundamentally everything is self-signed at its root. Who your systems trust 
depends on which certificates are installed in your system CA bundles,  which 
can be something Ansible takes care of or some other magic - you can distribute 
corporate CA certs or even specificly created local CA certs depending on your 
requirements.

A note on ephemeral certs - (Anchor or otherwise) the point here is that 
revocation works pretty poorly in Linux and especially poorly with the crypto 
libraries available to python today (CRL distribution is pretty 
non-deterministic at scale and OCSP just isn't supported) so in reality, your 
best mechanism could be to issue only short term certificates and replace them 
often, if you need to revoke a certificate you don't replace it. This technique 
is actually pretty CA agnostic, I imagine you could easily configure Dogtag, 
FreeIPA, EJBCA, ADCS etc to issue short life certificates.

The sticking point with short-life certificates is that the lifecycle is so 
short that when working at any sort of scale automated certificate signing is 
required, so robust policy management is required, automating a large part of 
what a traditional Registration Authority (RA) would do - which is a problem 
we've tried to solve with Anchor.

So I guess for any project you need to consider how/if revocation will work, in 
truth most of the time it doesn't, we pretend it does and carry on worrying 
about making sure we use publicly signed certificates.

I agree that running a local letsencrypt has a lot of promise here, it again 
looks at replacing a traditional RA with various proofs of possession or 
control (like control of specific DNS records etc).

There are ways to make most services play nice with ephemeral certificates - 
generally it involves front ending the service with a TLS terminator or LB - 
we've found through testing that they're generally pretty good at having 
certificates (and keys) swapped out from under them.



__
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] [openstack-ansible][security] Creating a CA for openstack-ansible deployments?

[Clark, Robert Graham]

On 29/10/2015 21:43, "Major Hayden"  wrote:



>On 10/29/2015 04:33 AM, McPeak, Travis wrote:
>> 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.
>
>This is certainly true.  However, I'd like to solve for the use of self-signed 
>SSL certificates in openstack-ansible first.
>
>At the moment, each self-signed certificate for various services is generated 
>within each role.  The goal would be to make a CA at the beginning and then 
>allow roles to utilize another role/task to issue certificates from that CA.  
>The CA would most likely be located on the deployment host.
>
>Deployers who are very security conscious can provide keys, certificates, and 
>CA certificates in the deployment configuration and those will be used instead 
>of generating self-signed certificates.
>
>--
>Major Hayden

It sounds like what you probably need is a lightweight CA, without revocation, 
that gives you some basic constraints by which you can restrict certificate 
issuance to just your ansible tasks and that could potentially be thrown away 
when it’s no longer required. Particularly something light enough that it could 
live on any deployment/installer node.

This sounds like it _might_ be a good fit for Anchor[1], though possibly not if 
I’ve misunderstood your use-case.

[1] https://wiki.openstack.org/wiki/Security#Anchor_-_Ephemeral_PKI

Cheers
-Rob
__
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] [Security] Meetup / Lunch

[Clark, Robert Graham]

We have two fishbowls sessions on Thursday with lunch in the middle. I know 
there are security talks going on around the same times, this was unavoidable.

Perhaps we could all meet up for lunch on thursday, maybe by the prince hotel 
pool? (Off the marketplace)

Looking forward to meeting up with those of you I haven’t already seen!

-Rob
__
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] [security] The first version of the Logo for Openstack Security Project

[Clark, Robert Graham]

I had looped some people into a previous version of the thread but they've not 
replied yet.

I think we ran into this problem before and got a firm "maybe, depending on 
what it is" from the powers-that-be.

Perhaps we should look at a rough-draft alternative logo while we await a 
verdict?

> -Original Message-
> From: michael mccune [mailto:m...@redhat.com]
> Sent: 21 October 2015 17:27
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
> Openstack Security Project
> 
> On 10/21/2015 03:54 AM, Michael Xin wrote:
> > Hi, guys:
> > Thanks for your help. We are designing a logo and a flyer for Openstack
> > Security Project. Rachel helped us with the task. Attached is her first
> > version of the logo. Please let us know your feedback.
> >
> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
> > Thanks and have a great day.
> 
> hi Michael, thanks to Rachel for putting this together. i like the
> general concept of the openstack logo as a lock. i think the "lock
> parts" could have a little more depth on them.
> 
> you had asked in irc about usage of the openstack logo, i'm not sure.
> but this page, https://www.openstack.org/brand/openstack-logo/ , seems
> to indicate that the usage is pretty limited. in specific, this section
> "You agree that you will not (i) alter or modify the OpenStack Logo as
> provided by the OpenStack Foundation; " seems to indicate that we may
> not be able to use the logo like this. we should probably ask someone
> from the foundation.
> 
> all in all though, a nice effort. many thanks =)
> 
> mike
> 
> 
> __
> 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] [security] The first version of the Logo for Openstack Security Project

[Clark, Robert Graham]

Wow, that looks amazing. 

It's pretty late my time so I'll take a closer look at the text tomorrow but 
the overall look and style is superb! Thank you for all the effort that's gone 
into this!

> -Original Message-
> From: Michael Xin [mailto:michael@rackspace.com]
> Sent: 21 October 2015 22:11
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: openstack-secur...@lists.openstack.org
> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
> Openstack Security Project
> 
> Rob and Michael:
> Thanks for the update. We will probably not use any Openstack Logo.
> 
> Here is the first draft of the flyer:
> 
> http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf
> 
> 
> Please send us your feedback.
> 
> 
> Yours,
> Michael
> 
> 
> 
> 
> 
> On 10/21/15, 11:32 AM, "Clark, Robert Graham" <robert.cl...@hpe.com> wrote:
> 
> >I had looped some people into a previous version of the thread but they've 
> >not replied yet.
> >
> >I think we ran into this problem before and got a firm "maybe, depending on 
> >what it is" from the powers-that-be.
> >
> >Perhaps we should look at a rough-draft alternative logo while we await a 
> >verdict?
> >
> >> -Original Message-
> >> From: michael mccune [mailto:m...@redhat.com]
> >> Sent: 21 October 2015 17:27
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
> >> Openstack Security Project
> >>
> >> On 10/21/2015 03:54 AM, Michael Xin wrote:
> >> > Hi, guys:
> >> > Thanks for your help. We are designing a logo and a flyer for Openstack
> >> > Security Project. Rachel helped us with the task. Attached is her first
> >> > version of the logo. Please let us know your feedback.
> >> >
> >> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
> >> > Thanks and have a great day.
> >>
> >> hi Michael, thanks to Rachel for putting this together. i like the
> >> general concept of the openstack logo as a lock. i think the "lock
> >> parts" could have a little more depth on them.
> >>
> >> you had asked in irc about usage of the openstack logo, i'm not sure.
> >> but this page, https://www.openstack.org/brand/openstack-logo/ , seems
> >> to indicate that the usage is pretty limited. in specific, this section
> >> "You agree that you will not (i) alter or modify the OpenStack Logo as
> >> provided by the OpenStack Foundation; " seems to indicate that we may
> >> not be able to use the logo like this. we should probably ask someone
> >> from the foundation.
> >>
> >> all in all though, a nice effort. many thanks =)
> >>
> >> mike
> >>
> >>
> >> __
> >> 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

__
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] [Security] Introducing Killick PKI

[Clark, Robert Graham]

> -Original Message-
> From: Adam Young [mailto:ayo...@redhat.com]
> Sent: 12 October 2015 02:24
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Security] Introducing Killick PKI
> 
> On 10/11/2015 06:50 PM, Robert Collins wrote:
> > On 9 October 2015 at 06:47, Adam Young  wrote:
> >> On 10/08/2015 12:50 PM, Chivers, Doug wrote:
> >>> Hi All,
> >>>
> >>> At a previous OpenStack Security Project IRC meeting, we briefly discussed
> >>> a lightweight traditional PKI using the Anchor validation functionality, 
> >>> for
> >>> use in internal deployments, as an alternative to things like MS ADCS. To
> >>> take this further, I have drafted a spec, which is in the security-specs
> >>> repo, and would appreciate feedback:
> >>>
> >>> https://review.openstack.org/#/c/231955/
> >>>
> >>> Regards
> >>>
> >>> Doug
> >> How is this better than Dogtag/FreeIPA?
> > DogTag is Tomcat yeah? Thats no exactly trivial to deploy - the spec
> > specifically calls out the desire to have a low-admin-overhead
> > solution. Perhaps DogTag/FreeIPA are that in the context of a RHEL
> > environment? I see that the dogtag-pki packages in Debian are up to
> > date - perhaps more discussion w/ops is needed?
> 
> Tomcat is trivial to deploy; it is in all the major distributions
> already. Dogtag is slightly more complex because it does things right
> WRT security hardening the Tomcat instance.  But the process is
> automated as part of the Dogtag code base.
> 
> A better bet is using Dogtag as installed with FreeIPA. It is supported
> in both Debian based and RPM based distributions.  The dev team is
> primarily Red Hat, with an Ubuntu packager dealing with the headaches of
> getting it installed there.  There is someone working on SuSE already as
> well.  FreeIPA gets us Dogtag, as well as Kerberos for Symmetric Key.
> 
> We have a demo of Using Kerberos to authenticate and encrypt the
> messaging backend (AMQP 1.0 Driver with Proton) and also for auth on all
> of the Web services.  I'll be one of the people demoing it at the Red
> Hat booth at Tokyo if you want to see it and ask questions directly.
> 
> For Self Signed certificates, we can use certmonger and the self-signed
> backend; we should be using Certmonger as the cert management client no
> matter what.  There was a Certmonger- Barbican plugin underway, but I do
> not know the status of it.
> 
> 
> Let's not reinvent this; the security and cryptography focused people on
> OpenStack are already spread thin. Lets focus on reusing pre-existing
> solutions.
> 
> 
> 

There's very little out there in terms of easy to use, deploy and scale PKI 
systems. ADCS is very tightly coupled to Windows, EJBCA is clunky, pyCA isn't 
supported anymore afaik and my personal experience with Dogtag (YMMV of course) 
is that it was difficult to setup and maintain. Now that was some time ago, 
when the available documentation didn't match with the shipping version and 
Ubuntu support wasn't a thing so I'm sure it's moved on now and it's possibly 
great - but - that's no reason to not have a crack at making something better. 
(For some personal interpretation of "better").

Reinvention can be good, after all, if it wasn't OpenStack probably wouldn't be 
a thing.

-Rob

__
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] [openstack-ansible] Reviews needed: openstack-ansible-security

[Clark, Robert Graham]

It might be worth re-posting this with a [Security] tag. 

I know a number of us from the Security project have been quietly keeping tabs 
on this, it seems like great work. We didn't want to wade in because clearly 
things were already moving with some good momentum and there's no need for us 
to try and own everything security-related. 

However, now you're asking for review I'll make sure this gets discussed at 
today's weekly Security meeting [r1] and hopefully we'll get some reviews 
flowing.

[r1] https://etherpad.openstack.org/p/security-20151008-irc

Cheers
-Rob


> -Original Message-
> From: Major Hayden [mailto:ma...@mhtx.net]
> Sent: 08 October 2015 15:27
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [openstack-ansible] Reviews needed: 
> openstack-ansible-security
> 
> Hey folks,
> 
> Now that the openstack-ansible-security role has been added to OpenStack, 
> we're in need of some reviews[1]!
> 
> Many of these reviews are fairly easy to do as they involve a task or two 
> plus a small amount of documentation.  Some reviews involve only
> documentation.  You can refer to each STIG requirement quickly using the STIG 
> Viewer[2].  It's a great way for new folks to get started with
> reviews. ;)
> 
> Feel free to ask me any questions about any of the patches.  I'm in 
> #openstack-ansible on Freenode as 'mhayden'.
> 
> [1] 
> https://review.openstack.org/#/q/status:open+project:openstack/openstack-ansible-security,n,z
> [2] https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/
> 
> --
> Major Hayden
> 
> __
> 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-dev] [Barbican][Security] Automatic Certificate Management Environment

[Clark, Robert Graham]

Hi All,

So I did a bit of tyre kicking with Letsencrypt today, one of the things I 
thought was interesting was the adherence to the burgeoning Automatic 
Certificate Management Environment (ACME) standard.

https://letsencrypt.github.io/acme-spec/

It’s one of the more readable crypto related standards drafts out there, 
reading it has me wondering how this might be useful for Anchor, or indeed for 
Barbican where things get quite interesting, both at the front end (enabling 
ACME clients to engage with Barbican) or at the back end (enabling Barbican to 
talk to any number of ACME enabled CA endpoints.

I was wondering if there’s been any discussion/review here, I’m new to ACME but 
I’m not sure if I’m late to the party…

Cheers
-Rob

__
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] [Security] Weekly Meeting Agenda

[Clark, Robert Graham]

Hi All,

I won't be available to run the weekly meeting tomorrow as I'm out travelling, 
Michael McCune (elmiko) has volunteered to lead the meeting.

There's IRC information on our wiki page : 
https://wiki.openstack.org/wiki/Security

Agenda items (Please reply to add any more):

*PTL Shenanigans : https://review.openstack.org/#/c/224798/

*VMT Project Tracking : https://review.openstack.org/#/c/226869/

*Anchor (Ephemeral PKI)

*Bandit (Security Linter)

*Developer Guidance (Don't do this)

*Security Documents (Do do this)

*Security Notes (Think about not doing this)

*Syntribos (API Fuzzing)

*Any Other Business

Have a good meeting all!

-Rob
__
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] [Neutron] Separate floating IP pools?

[Clark, Robert Graham]

Is it possible to have separate floating-IP pools and grant a tenant access to 
only some of them?

Thought popped into my head while looking at the rbac-network spec here: 
https://review.openstack.org/#/c/132661/4/specs/liberty/rbac-networks.rst

Creating individual pools, allowing only some tenants access and having 
off-cloud network ACLs would get part way to satisfying the use cases that 
drive the above spec (I'm thinking of this as a more short term solution, 
certainly not a direct alternative).

I'm sure this is answered elsewhere but I couldn't find any direct information 
so I'm assuming no, it isn't supported but I wonder how much effort would be 
required to make it work?
-Rob
__
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] [all][elections] PTL nomination period is now over

[Clark, Robert Graham]

Likewise, I'm not sure I missed the candidacy window, I think our late 
mid-cycle threw things out of whack slightly.

When I saw the Magnum nomination I made a mental note to apply today. This is a 
poor-show on my part and I apologise to the TC, the community and the Security 
team for this apparent lack of awareness. 

Five projects without candidates seems like a lot, especially as several of 
them are very active. I think perhaps this is a busy time of year and like me a 
number of people were not paying close enough attention to the election window.

I understand that the official window for nominations has now closed, I'd like 
to understand more about how the process detailed in [1] below will operate, 
many of these projects have established PTLs (like me) who are obviously not 
great at tracking dates (like me) but still very much want to continue to lead 
in their communities (like me). I'd like to better understand what happens next.

-Rob



> -Original Message-
> From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com]
> Sent: 17 September 2015 14:56
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][elections] PTL nomination period is now 
> over
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> This is quite unfortunate, as I was intending to submit my candidacy
> for the Barbican project today, but I did not realize the cutoff time
> would be in the morning in CDT.
> 
> I'd like to apologize to the OpenStack community and the Barbican team
> in particular for missing this deadline.
> 
> Thanks,
> 
> Douglas Mendizábal
> 
> On 9/17/15 8:49 AM, Flavio Percoco wrote:
> > On 17/09/15 13:44 +, Tristan Cacqueray wrote:
> >> On 09/17/2015 01:32 PM, Flavio Percoco wrote:
> >>> On 17/09/15 13:25 +, Tristan Cacqueray wrote:
>  PTL Nomination is now over. The official candidate list is
>  available on the wiki[0].
> 
>  There are 5 projects without candidates, so according to
>  this resolution[1], the TC we'll have to appoint a new PTL
>  for Barbican, MagnetoDB, Magnum, Murano and Security
> >>>
> >>> Magnum had a candidacy on the mailing list. I'd assume this is
> >>> because it wasn't proposed to openstack/election. Right?
> >>
> >> That is correct, but the candidacy was submitted after the
> >> deadlines so we can't validate this candidate.
> >
> > Awesome, thanks for the confirmation. Flavio
> >
> >>
> >>>
> >>> Thanks for the hard work here, Flavio
> >>>
> 
>  There are 7 projects that will have an election: Cinder,
>  Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The
>  details for those will be posted tomorrow after Tony and I
>  setup the CIVS system.
> 
>  Thank you, Tristan
> 
> 
>  [0]:
>  https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confir
> med_Candidates
> 
> 
> 
> 
> [1]:
>  http://governance.openstack.org/resolutions/20141128-elections-proc
> ess-for-leaderless-programs.html
> 
> 
> 
> 
> >>>
> >>>
> >>>
> 
> 
> 
> __
> 
> 
>  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
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - https://gpgtools.org
> 
> iQIcBAEBCgAGBQJV+saCAAoJEB7Z2EQgmLX7XG0P/AqOTGDDbVJrJSTPnCGwtqYd
> 275uDQgWqvbsGMKOrfKO7GBgI/5n/j8hCyiipq6niCfW5eWWH7rYgU1pLKLjiZmR
> 12Ui4PwkqvoJEa0J5NIiM8GOrt2TEDTu7vOQAWMzGEn+8fbs7Z9MRPIAg7bEXuk0
> eQNs5LK6j/INXvuuKm4ZV2MjAxJRbtsSZYVn59U4IxM0GSJIC4MLu8dGaRzf+G8B
> 881hflBskg1Sa5UjEcj/yMUDrtBLOyNkM67dv8M9ojNB0bX3o+US8zmJnsbk6whD
> ox3GrgoxT8he6iMNd/YYycFtBlBZ4fqNN8Uv5Vr/+k8s2umJf7Y3IbM2oQuhM1oJ
> mWuwFbyc440ep9WkBeXeZTm0S0FYwR3MS40nW2D04eHEcTbCHchKIoLp/tO0AKYP
> op116JlzTyWZatywL8rIOner4UJQX6yUqmGRdonACNQ6OAzTLTTaARtwqHacxL81
> UqzOLEQ8nW9p5xCTPWhbPbR7t1T7ngwf5bJAuDKVx9JDUsM+mYjZ7smWdg+PV1yS
> SwW94TzImOV4ujiT7AwzUBz6SZ0jHFt5yXVWscggpj5k7l8lPqFhd4xQVvidqLcZ
> VsHfKwfdfWX22z+97n4/GjEd6B0seZqcxoP4qVsXXgpuFJETVLEifDM9DTOLccxy
> xQR6UpOxTZxl5EdiOpxX
> =nraX
> -END PGP SIGNATURE-
> 
> 

[openstack-dev] [Security] Leadership / Participation in PTL elections.

[Clark, Robert Graham]

Security Folks,

Some how I missed the window to nominate myself as a PTL candidate for
Security. I have literally no idea how I missed it. I’ve been working on
Security project things all week (Anchor and OSSNs mainly) so it’s not like I
wasn’t thinking about the Security team!

Anyway, I missed the voting window (as did a few others it would seem) and this
makes me very sad, the PTL position will now be decided by the OpenStack
technical committee in line with:

http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

Although it will get –2 because it is late, I have submitted my candidacy
anyway because I wanted to express how much I’d like to continue working to
drive Security standard up in OpenStack by helping to keep our many security
projects moving along. My candidacy request can be seen here:

https://review.openstack.org/224798

My most sincere apologies,
-Rob

__
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] [openstack-ansible] Security hardening

[Clark, Robert Graham]

Very interesting discussion.

The Security project has a published security guide that I believe this
would be very appropriate content for, the current guide (for reference)
is here: http://docs.openstack.org/sec/

Contributions welcome, just like any other part of the OpenStack docs :)

-Rob

On 15/09/2015 16:05, "Jeff Keopp"  wrote:

>This is a very interesting proposal and one I believe is needed.  I¹m
>currently looking at hardening the controller nodes from unwanted access
>and discovered that every time the controller node is booted/rebooted, it
>flushes the iptables and writes only those rules that neutron believes
>should be there.  This behavior would render this proposal ineffective
>once the node is rebooted.
>
>So I believe neutron needs to be fixed to not flush the iptables on each
>boot, but to write the iptables to /etc/sysconfig/iptables and then
>restore them as a normal linux box should do.  It should be a good citizen
>with other processes.
>
>A sysadmin should be allowed to use whatever iptables handlers they wish
>to implement security policies and not have an OpenStack process undo what
>they have set.
>
>I should mention this is on a system using a flat network topology and
>bare metal nodes.  No VMs.
>
>‹
>Jeff Keopp | Sr. Software Engineer, ES Systems.
>380 Jackson Street | St. Paul, MN 55101 | USA  | www.cray.com
>
>
>
>
>
>-Original Message-
>From: Major Hayden 
>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>
>Date: Monday, September 14, 2015 at 11:34
>To: "openstack-dev@lists.openstack.org"
>
>Subject: Re: [openstack-dev] [openstack-ansible] Security hardening
>
>>On 09/14/2015 03:28 AM, Jesse Pretorius wrote:
>>> I agree with Clint that this is a good approach.
>>> 
>>> If there is an automated way that we can verify the security of an
>>>installation at a reasonable/standardised level then I think we should
>>>add a gate check for it too.
>>
>>Here's a rough draft of a spec.  Feel free to throw some darts.
>>
>>  https://review.openstack.org/#/c/222619/
>>
>>--
>>Major Hayden
>>
>>_
>>_
>>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

[openstack-dev] [Security] Weekly meeting cancelled due to Mid-Cycle

[Clark, Robert Graham]

Security folks,

Tomorrow’s mid-cycle is cancelled due to many of us attending the Mid-cycle.

-Rob


__
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] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

I’ve requested several Security Project slots on the summit timetable, I’d
be happy to dedicate a fishbowl session to this on the security track.

-Rob

On 01/09/2015 14:31, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>Awesome. Thanks. :)
>
>Are there any plans for the summit yet? I think we should all get
>together and talk about it.
>
>Thanks,
>Kevin
>________
>From: Clark, Robert Graham [robert.cl...@hp.com]
>Sent: Tuesday, September 01, 2015 1:35 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [magnum] Difference between certs stored in
>keystone and certs stored in barbican
>
>Extremely interesting.
>
>This is something that we are looking at during the Security mid-cycle
>(happening this week) see "Secure communications between control plane and
>tenant plane” under
>https://etherpad.openstack.org/p/security-liberty-midcycle
>
>This is problem for a lot of different projects, we’ve added your
>blueprint and hopefully we’ll be able to help with this moving forward.
>
>-Rob
>
>
>
>On 01/09/2015 11:11, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
>
>>https://blueprints.launchpad.net/nova/+spec/instance-users
>>
>>Please see the above spec. Nova, Keystone and Barbican have been working
>>together on it this cycle and are hoping to implement it in Mitaka
>>
>>The problem of secrets from the secret store is not isolated to just
>>Magnum.
>>
>>Thanks,
>>Kevin
>>
>>From: John Dennis [jden...@redhat.com]
>>Sent: Tuesday, September 01, 2015 10:03 AM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [magnum] Difference between certs stored in
>>keystone and certs stored in barbican
>>
>>On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:
>>>
>>>> The reason that is compelling is that you can have Barbican generate,
>>>> sign, and store a keypair without transmitting the private key over
>>>>the
>>>> network to the client that originates the signing request. It can be
>>>> directly stored, and made available only to the clients that need
>>>>access
>>>> to it.
>>>
>>> This is absolutely _not_ how PKI for TLS is supposed to work, yes
>>>Barbican
>>> can create keypairs etc because sometimes that¹s useful but in the
>>> public-private PKI model that TLS expects this is completely wrong.
>>>Magnum
>>> nodes should be creating their own private key and CSR and submitting
>>>them
>>> to some CA for signing.
>>>
>>> Now this gets messy because you probably don¹t want to push keystone
>>> credentials onto each node (that they would use to communicate with
>>> Barbican).
>>>
>>> I¹m a bit conflicted writing this next bit because I¹m not particularly
>>> familiar with the Kubernetes/Magnum architectures and also because I¹m
>>>one
>>> of the core developers for Anchor but here goesŠ.
>>>
>>> Have you considered using Anchor for this? It¹s a pretty lightweight
>>> ephemeral CA that is built to work well in small PKI communities (like
>>>a
>>> Kubernetes cluster) you can configure multiple methods for
>>>authentication
>>> and build pretty simple validation rules for deciding if a host should
>>>be
>>> given a certificate. Anchor is built to provide short-lifetime
>>> certificates where each node re-requests a certificate typically every
>>> 12-24 hours, this has some really nice properties like ³passive
>>> revocation² (Think revocation that actually works) and strong ways to
>>> enforce issuing logic on a per host basis.
>>>
>>> Anchor or not, I¹d like to talk to you more about how you¹re attempting
>>>to
>>> secure Magnum - I think it¹s an extremely interesting project that I¹d
>>> like to help out with.
>>>
>>> -Rob
>>> (Security Project PTL / Anchor flunkie)
>>
>>Let's not reinvent the wheel. I can't comment on what Magnum is doing
>>but I do know the members of the Barbican project are PKI experts and
>>understand CSR's, key escrow, revocation, etc. Some of the design work
>>is being done by engineers who currently contribute to products in use
>>by the Dept. of Defense, an agency that takes their PKI infrastructure
>>very seriously. They also have been involved with Keystone. I work with
>>these engineers on a regular basis.

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

On 01/09/2015 11:38, "Douglas Mendizábal"
<douglas.mendiza...@rackspace.com> wrote:

This turned into exactly what I was trying to avoid, I probably shouldn’t
have mentioned Anchor, but as I started us down this road (where really I
was just expressing some concerns over certificate lifecycle) please see
my comments below :)

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Added a few comments inline.
>
>- - Douglas Mendizábal
>
>On 9/1/15 12:03 PM, John Dennis wrote:
>> On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:
>>> 
>>>> The reason that is compelling is that you can have Barbican
>>>> generate, sign, and store a keypair without transmitting the
>>>> private key over the network to the client that originates the
>>>>  signing request. It can be directly stored, and made available
>>>>  only to the clients that need access to it.
>>> 
>>> This is absolutely _not_ how PKI for TLS is supposed to work,
>>> yes Barbican can create keypairs etc because sometimes that¹s
>>> useful but in the public-private PKI model that TLS expects this
>>> is completely wrong. Magnum nodes should be creating their own
>>> private key and CSR and submitting them to some CA for signing.
>>> 
>
>Barbican provides a lot of options for provisioning certificates. We
>do support provisioning certs by only passing a CSR so that clients
>can keep ownership of their keys, if that's what the client prefers.
>
>Of course, when you're provisioning keys for every node in a cluster
>for many clusters then key management becomes an issue, and if these
>are not throwaway keys, then storing them in Barbican makes sense.
>
>We can also provision the keys, and create CSRs on the Barbican side,
>so we make it very easy for clients who don't want to do any of this
>locally.

I wasn’t bashing Barbican, just the way that it looks like it’s being used
here, as I said, there’s good reasons why Barbican works the way it does,
but not all available options are appropriate for all types of deployments.



>
>>> Now this gets messy because you probably don¹t want to push
>>> keystone credentials onto each node (that they would use to
>>> communicate with Barbican).
>>> 
>
>Kevin Fox is working on a Nova spec to provide identity to VMs. I'm
>really hoping this spec gains some traction because it's a problem
>that not only Barbican, but all other user-facing projects can benefit
>from.
>
>See: https://blueprints.launchpad.net/nova/+spec/instance-users
>
>>> I¹m a bit conflicted writing this next bit because I¹m not
>>> particularly familiar with the Kubernetes/Magnum architectures
>>> and also because I¹m one of the core developers for Anchor but
>>> here goesŠ.
>>> 
>>> Have you considered using Anchor for this? It¹s a pretty
>>> lightweight ephemeral CA that is built to work well in small PKI
>>>  communities (like a Kubernetes cluster) you can configure
>>> multiple methods for authentication and build pretty simple
>>> validation rules for deciding if a host should be given a
>>> certificate. Anchor is built to provide short-lifetime
>>> certificates where each node re-requests a certificate typically
>>>  every 12-24 hours, this has some really nice properties like
>>> ³passive revocation² (Think revocation that actually works) and
>>> strong ways to enforce issuing logic on a per host basis.
>>> 
>
>Someone from the Magnum team can correct me if I'm wrong, but I do
>believe they considered Anchor for certificate provisioning.
>
>As I understand the Magnum use case, they will be provisioning many
>clusters across different tenants. While Anchor would work well for a
>single cluster, they need the ability to provision new CA roots for
>each and every cluster, and then provision certs off that root for
>every node in the cluster. This way node certs are only valid in the
>context of the cluster.
>
>A new feature for Barbican Liberty will be the ability to add new CA
>roots scoped to a tenant via API, which will address the Magnum
>requirements of separating the certificate roots per cluster.

Interestingly, we recently added support for this, you can have multiple
CA roots within Anchor. When we announced it a few summits back we
focussed on how you can use Anchor in silo’d deployments where you would
spin up an instance for each cluster but recently we added the ability to
run Anchor with multiple CA roots, each can have it’s own auth and it’s
own validation chain.


>
>>> Anchor or not, I¹d like to talk to you more about how you¹re
>>> attempting to secu

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

Extremely interesting.

This is something that we are looking at during the Security mid-cycle
(happening this week) see "Secure communications between control plane and
tenant plane” under
https://etherpad.openstack.org/p/security-liberty-midcycle

This is problem for a lot of different projects, we’ve added your
blueprint and hopefully we’ll be able to help with this moving forward.

-Rob



On 01/09/2015 11:11, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>https://blueprints.launchpad.net/nova/+spec/instance-users
>
>Please see the above spec. Nova, Keystone and Barbican have been working
>together on it this cycle and are hoping to implement it in Mitaka
>
>The problem of secrets from the secret store is not isolated to just
>Magnum.
>
>Thanks,
>Kevin
>
>From: John Dennis [jden...@redhat.com]
>Sent: Tuesday, September 01, 2015 10:03 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [magnum] Difference between certs stored in
>keystone and certs stored in barbican
>
>On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:
>>
>>> The reason that is compelling is that you can have Barbican generate,
>>> sign, and store a keypair without transmitting the private key over the
>>> network to the client that originates the signing request. It can be
>>> directly stored, and made available only to the clients that need
>>>access
>>> to it.
>>
>> This is absolutely _not_ how PKI for TLS is supposed to work, yes
>>Barbican
>> can create keypairs etc because sometimes that¹s useful but in the
>> public-private PKI model that TLS expects this is completely wrong.
>>Magnum
>> nodes should be creating their own private key and CSR and submitting
>>them
>> to some CA for signing.
>>
>> Now this gets messy because you probably don¹t want to push keystone
>> credentials onto each node (that they would use to communicate with
>> Barbican).
>>
>> I¹m a bit conflicted writing this next bit because I¹m not particularly
>> familiar with the Kubernetes/Magnum architectures and also because I¹m
>>one
>> of the core developers for Anchor but here goesŠ.
>>
>> Have you considered using Anchor for this? It¹s a pretty lightweight
>> ephemeral CA that is built to work well in small PKI communities (like a
>> Kubernetes cluster) you can configure multiple methods for
>>authentication
>> and build pretty simple validation rules for deciding if a host should
>>be
>> given a certificate. Anchor is built to provide short-lifetime
>> certificates where each node re-requests a certificate typically every
>> 12-24 hours, this has some really nice properties like ³passive
>> revocation² (Think revocation that actually works) and strong ways to
>> enforce issuing logic on a per host basis.
>>
>> Anchor or not, I¹d like to talk to you more about how you¹re attempting
>>to
>> secure Magnum - I think it¹s an extremely interesting project that I¹d
>> like to help out with.
>>
>> -Rob
>> (Security Project PTL / Anchor flunkie)
>
>Let's not reinvent the wheel. I can't comment on what Magnum is doing
>but I do know the members of the Barbican project are PKI experts and
>understand CSR's, key escrow, revocation, etc. Some of the design work
>is being done by engineers who currently contribute to products in use
>by the Dept. of Defense, an agency that takes their PKI infrastructure
>very seriously. They also have been involved with Keystone. I work with
>these engineers on a regular basis.
>
>The Barbican blueprint states:
>
>Barbican supports full lifecycle management including provisioning,
>expiration, reporting, etc. A plugin system allows for multiple
>certificate authority support (including public and private CAs).
>
>Perhaps Anchor would be a great candidate for a Barbican plugin.
>
>What I don't want to see is spinning our wheels, going backward, or
>inventing one-off solutions to a very demanding and complex problem
>space. There have been way too many one-off solutions in the past, we
>want to consolidate the expertise in one project that is designed by
>experts and fully vetted, this is the role of Barbican. Would you like
>to contribute to Barbican? I'm sure your skills would be a tremendous
>asset.
>
>
>--
>John
>
>__
>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/ope

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Clark, Robert Graham]

>The reason that is compelling is that you can have Barbican generate,
>sign, and store a keypair without transmitting the private key over the
>network to the client that originates the signing request. It can be
>directly stored, and made available only to the clients that need access
>to it.

This is absolutely _not_ how PKI for TLS is supposed to work, yes Barbican
can create keypairs etc because sometimes that¹s useful but in the
public-private PKI model that TLS expects this is completely wrong. Magnum
nodes should be creating their own private key and CSR and submitting them
to some CA for signing.

Now this gets messy because you probably don¹t want to push keystone
credentials onto each node (that they would use to communicate with
Barbican).

I¹m a bit conflicted writing this next bit because I¹m not particularly
familiar with the Kubernetes/Magnum architectures and also because I¹m one
of the core developers for Anchor but here goesŠ.

Have you considered using Anchor for this? It¹s a pretty lightweight
ephemeral CA that is built to work well in small PKI communities (like a
Kubernetes cluster) you can configure multiple methods for authentication
and build pretty simple validation rules for deciding if a host should be
given a certificate. Anchor is built to provide short-lifetime
certificates where each node re-requests a certificate typically every
12-24 hours, this has some really nice properties like ³passive
revocation² (Think revocation that actually works) and strong ways to
enforce issuing logic on a per host basis.

Anchor or not, I¹d like to talk to you more about how you¹re attempting to
secure Magnum - I think it¹s an extremely interesting project that I¹d
like to help out with.

-Rob
(Security Project PTL / Anchor flunkie)



__
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] Would people see a value in the cve-check-tool?

[Clark, Robert Graham]

Hi Elena,

This is interesting work, thanks for posting it (and for posting it here on 
openstack-dev, we are trying to wind down the security ML) though maybe use the 
[Security] tag in the subject line next time.

I think this is a very interesting project, though it’s unclear to me who might 
be the targeted users for this? It seems like it would make the most sense for 
this to be in the gate. Now this could be the standard build gates (Jenkins 
etc) but I’m not sure how much sense that makes on its own, after all most 
production consumers (those who care about CVEs) of OpenStack are probably not 
consuming it vanilla from source but are more likely to be consuming it from a 
vendor who’s already packaged it up.

In the latter case, I’m sure vendors would find this tool very useful, we do 
something similar at HP today but I’m sure a tool like this would add value and 
it’s probably something we could contribute to.

As I write this I’ve realised that there would be an interesting possibility in 
the former case (putting this in the upstream OpenStack gates). It would be 
interesting to see something running that regularly checks for CVE’s in the 
libraries that _could_ be included in OpenStack, (library requirements within 
OpenStack often include more than one version) and bumps the version to the 
next safest and submits a change request for manual verification etc.

-Rob







From: Adam Heczko [mailto:ahec...@mirantis.com]
Sent: 03 August 2015 23:18
To: OpenStack Development Mailing List (not for usage questions)
Cc: Heath, Constanza M; Ding, Jian-feng; Demeter, Michael; Bhandaru, Malini K
Subject: Re: [openstack-dev] Would people see a value in the cve-check-tool?

Hi Elena, the tool looks very interesting.
Maybe try to spread out this proposal also through openstack-security@ ML.
BTW, I can't find the wrapper mentioned - am I missing something?

Regards,

Adam

On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena 
elena.reshet...@intel.commailto:elena.reshet...@intel.com wrote:
Hi,

We would like to ask opinions if people find it valuable to include a 
cve-check-tool into the OpenStack continuous integration process?
A tool can be run against the package and module dependencies of OpenStack 
components and detect any CVEs (in future there are also plans to integrate 
more functionality to the tool, such as scanning of other vulnerability 
databases and etc.). It would not only provide fast detection of new 
vulnerabilities that are being released for existing dependencies, but also 
control that people are not introducing new vulnerable dependencies.

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

I am attaching an example of a very simple Python wrapper for the tool, which 
is able to process formats like: 
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
and an example of html output if you would be running it for the python module 
requests 2.2.1 version (which is vulnerable to 3 CVEs).

Best Regards,
Elena.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Adam Heczko
Security Engineer @ Mirantis Inc.
__
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] [Security] Midcycle Announcement

[Clark, Robert Graham]

 -Original Message-
 From: Thierry Carrez [mailto:thie...@openstack.org]
 Sent: 06 July 2015 09:12
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Security] Midcycle Announcement
 
 Clark, Robert Graham wrote:
  The Security Project will be holding it's mid-cycle meet-up in Seattle
  1st to 4^th .
  [..]
 
 Please add it to https://wiki.openstack.org/wiki/Sprints for reference.
 

Done - Also created an accompanying wiki page:
https://wiki.openstack.org/wiki/Sprints/SecurityLibertySprint

__
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] [Security] Midcycle Announcement

[Clark, Robert Graham]

Hi All,

The Security Project will be holding it's mid-cycle meet-up in Seattle 1st to 
4th.

Topic for the mid-cycle include:

*A sprint on v2 of the Security Guide

*Bootstrapping OpenStack Crypto Tracking and Verification Work

*Security Face - building the appropriate web pages for security

*Bandit Sprints

*Anchor Sprints

*Enhancing the developer guidelines

If you have an active interest in OpenStack Security and would like to come 
along please add your name to the etherpad, where you can also add any topics 
you think we should discuss.

https://etherpad.openstack.org/p/security-liberty-midcycle

-Rob

__
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] [Security][VMT] Promoting Michael McCune and Travis McPeak to Security CoreSec

[Clark, Robert Graham]

With various +1's and no objections I'm pleased to announce that Michael and 
Travis are now added to the ossg-coresec team.

This team assists the VMT with vulnerability metrics, triage and of course 
OpenStack Security Notes.

Congratulations both!

-Rob

__
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] [Security] the need about implementing a MAC security hook framework for OpenStack

[Clark, Robert Graham]

Hi Yang,

This is an interesting idea. Most operators running production OpenStack 
deployments will be using OS-level Mandatory Access Controls already (likely 
AppArmour or SELinux).

I can see where there might be some application on a per-service basis, 
introducing more security for Swift, Nova etc, I’m not sure what you could do 
that would be OpenStack-wide.

Interested to hear where you think work on this might go.

-Rob


From: Yang Luo [mailto:hslu...@gmail.com]
Sent: 17 June 2015 07:47
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Security] the need about implementing a MAC security 
hook framework for OpenStack

Hi list,

  I'd like to know the need about implementing a MAC (Mandatory Access Control) 
security hook framework for OpenStack, just like the Linux Security Module to 
Linux. It can be used to help construct a security module that mediates the 
communications between OpenStack nodes and controls distribution of resources 
(i.e., images, network, shared disks). This security hook framework should be 
cluster-wide, dynamic policy updating supported, non-intrusive implemented and 
with low performance overhead. The famous module in LSM, SELinux can also be 
imported into this security hook framework. In my point, as OpenStack has 
become a leading cloud operating system, it needs some kind of security 
architecture as standard OS.

I am a Ph.D student who has been following OpenStack security closely for 
nearly 1 year. This is just my initial idea and I know this project won't be 
small, so before I actually work on it, I'd like to hear your suggestions or 
objections about it. Thanks!

Best,
Yang
__
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] [Magnum] TLS Support in Magnum

[Clark, Robert Graham]

I think this is an interesting if somewhat difficult to follow thread.

It’s worth keeping in mind that there are more ways to handle certificates in 
OpenStack than just Barbican, though there are often good reasons to use it.

Is there a blueprint or scheduled IRC meeting to discuss the options? If useful 
I’d be happy to arrange for some folks from the Security Project to take a 
look, we spend a lot of time collectively dealing with TLS issues and might be 
able to help with the path-finding for TLS in Magnum.

-Rob

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: 17 June 2015 06:12
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum

Clint,

Hi! It’s good to hear from you!

On Jun 16, 2015, at 8:58 PM, Clint Byrum 
cl...@fewbar.commailto:cl...@fewbar.com wrote:

I don't understand at all what you said there.

If my kubernetes minions are attached to a gateway which has a direct
route to Magnum, let's say they're at, 192.0.2.{100,101,102}, and
Magnum is at 198.51.100.1, then as long as the minions' gateway knows
how to find 198.51.100.0/24, and Magnum's gateway knows how to route to
192.0.2.0/24, then you can have two-way communication and no floating
ips or NAT. This seems orthogonal to how external users find the minions.

That’s correct. Keep in mind that large clouds use layer 3 routing protocols to 
get packets around, especially for north/south traffic where public IP 
addresses are typically used. Injecting new routes into the network fabric each 
time we create a bay might cause reluctance from network administrators to 
allow the adoption of Magnum. Pre-allocating tons of RFC-1918 addresses to 
Magnum may also be impractical on networks that use those addresses 
extensively. Steve’s explanation of using routable addresses as floating IP 
addresses is one approach to leverage the prevailing SDN in the cloud’s network 
to address this concern.

Let’s not get too far off topic on this thread. We are discussing the 
implementation of TLS as a mechanism of access control for API services that 
run on networks that are reachable by the public. We got a good suggestion to 
use an approach that can work regardless of network connectivity between the 
Magnum control plane and the Nova instances (Magnum Nodes) and the containers 
that run on them. I’d like to see if we could use cloud-init to get the keys 
into the bay nodes (docker hosts). That way we can avoid the requirement for 
end-to-end network connectivity between bay nodes and the Magnum control plane.

Thanks,

Adrian

Excerpts from Steven Dake (stdake)'s message of 2015-06-16 19:40:25 -0700:

Clint,

Answering Clint’s question, yes there is a reason all nodes must expose a 
floating IP address.

In a Kubernetes cluster, each minion has a port address space.  When an 
external service contacts the floating IP’s port, the request is routed over 
the internal network to the correct container using a proxy mechanism.  The 
problem then is, how do you know which minion to connect to with your external 
service?  The answer is you can connect to any of them.  Kubernetes only has 
one port address space, so Kubernetes suffers from a single namespace problem 
(which Magnum solves with Bays).

Longer term it may make sense to put the minion external addresses on a RFC1918 
network, and put a floating VIF with a load balancer to connect to them.  Then 
no need for floating address per node.  We are blocked behind kubernetes 
implementing proper support for load balancing in OpenStack to even consider 
this work.

Regards
-steve

From: Fox, Kevin M 
kevin@pnnl.govmailto:kevin@pnnl.govmailto:kevin@pnnl.gov
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, June 16, 2015 at 6:36 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum

Out of the box, vms usually can contact the controllers though the routers nat, 
but not visa versa. So its preferable for guest agents to make the connection, 
not the controller connect to the guest agents. No floating ips, security group 
rules or special networks are needed then.

Thanks,
Kevin


From: Clint Byrum
Sent: Monday, June 15, 2015 6:10:27 PM
To: openstack-dev
Subject: Re: [openstack-dev] [Magnum] TLS Support in Magnum

Excerpts from Fox, Kevin M's message of 2015-06-15 15:59:18 -0700:

No, I was confused by your statement:
When we create a bay, we have an ssh keypair that we use to inject the ssh 
public key onto the nova instances we create.

It sounded like you were using that keypair to inject a public key. I just 
misunderstood.

It does raise the 

[openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec

[Clark, Robert Graham]

I'd like to nominate Travis for a CoreSec position as part of the Security 
project. - CoreSec team members support the VMT with extended consultation on 
externally reported vulnerabilities.

Travis has been an active member of the Security project for a couple of years 
he's a part of the bandit subproject and has been very active in discussions 
over this time. He's also found multiple vulnerabilities and has experience of 
the VMT process.

-Rob

__
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] [Security][VMT] OSSG CoreSec Positions

[Clark, Robert Graham]

All,

OSSG CoreSec is a private group on Launchpad, it consists of established 
Security Project team members who are on hand to be called in by the VMT to 
consult on vulnerabilities and discuss possible mitigations.

We require two new members, as with other project ‘cores’ I suggest a 
nominations process. If you’ve worked closely with someone from the Security 
Project whom you think would make a good member of the CoreSec team please 
nominate them by email with a Subject: “[Security] Nominating Joe Blogs for 
Security CoreSec” with a few words in the body to describe why you’d think that 
person would be a good fit.

If you agree with a nomination please +1 it.

Thanks
-Rob

__
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] [Security] [Bandit] Using multiprocessing/threading to speed up analysis

[Clark, Robert Graham]

Interesting work,

I guess my initial thought would be - does it need to be faster?

Will this work make maintenance and the addition of features more
difficult?

-Rob


On 08/06/2015 08:26, Ian Cordasco ian.corda...@rackspace.com wrote:

Hey everyone,

I drew up a blueprint
(https://blueprints.launchpad.net/bandit/+spec/use-threading-when-running-
c
hecks) to add the ability to use multiprocessing (or threading) to Bandit.
This essentially means that each thread will be fed a file and analyze
it and return the results. (A file will only ever be analyzed by one
thread.)

This has lead to significant speed improvements in Flake8 when running
against a project like Nova and I think the same improvements could be
made to Bandit.

I'd love some feedback on the following points:

1. Should this be on by default?

   Technically, this is backwards incompatible (unless we decide to order
the output before printing results) but since we're still in the 0.x
release series of Bandit, SemVer allows backwards incompatible releases. I
don't know if we want to take advantage of that or not though.

2. Is output ordering significant/important to people?

3. If this is off by default, should the flag accept a special value,
e.g., 'auto', to tell Bandit to always use the number of CPUs present on
the machine?

Cheers,
Ian

__
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] [security] Nominating Mike McCune as Security-Doc Core

[Clark, Robert Graham]

+1 from me

 On 22 May 2015, at 13:55, Nathan Kinder nkin...@redhat.com wrote:
 
 On 05/19/2015 05:20 PM, Dillon, Nathaniel wrote:
 To the Security and Docs groups as well as other interested parties, 
 
 I would like to nominate Mike McCune to the Security Guide core. He has been 
 contributing to the Security Guide for about six months now, and he has been 
 a consistent participant improving content and helping new submittors. In 
 addition, he knows the inner workings of the guide, having created and 
 merged for the security guide the chapter on Sahara.
 
 Please chime in with your agreement, or concerns.
 
 +1!  Mike's work has been great.
 
 -NGK
 
 
 Thanks,
 
 Nathaniel
 __
 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

[openstack-dev] [Security][Glance] Design session for image signing/encryption

[Clark, Robert Graham]

All,

Is there a session to discuss the image security proposal?  
https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst

Cheers
-Rob

__
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] [security] / IDS + openstack meeting in Vancouver 4:10 Wednesday May 20

[Clark, Robert Graham]

Sounds good, I¹m not sure if I¹ll be able to make it, or in fact if TaaS
is the way forward, there¹s a few different options in this space and
personally I like bump in the wire OVS - something to discuss :)

I¹ll try to make it but I expect this is will be a long running discussion.

Kind Regard

On 19/05/2015 14:29, Dan Lambright dlamb...@redhat.com wrote:

Hello,

While at the Vancouver summit, it would be good to have an informal
meeting on IDS + openstack. My understanding is there has not been a
community driven effort in this area to date. It would be good to kick
something off. Likely subjects would be neutron plug-ins and scalability
(management and monitoring).

The best time would probably be after the TaaS talk Wednesday. TaaS may
influence what direction to take.

I will be next to the ATM machine on the 1st floor, next to where they
give away the windbreaker SWAG. I¹ll hang out there between 4:10 and
4:30. Please feel free to find a drink and  walk over. I will also post
this announcement to the openstack-dev mailing list
(http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The
subject will contain: [security] {IDS}

Thanks,

Dan Lambright
Red Hat

__
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] [security] Consensus on security guidance license

[Clark, Robert Graham]

Agree

Sent from my iPhone

On 15 May 2015, at 10:17, Rob Fletcher 
rfletch@gmail.commailto:rfletch@gmail.com wrote:

sgtm

On Fri, May 15, 2015 at 10:04 AM, Paul McMillan 
p...@mcmillan.wsmailto:p...@mcmillan.ws wrote:

Works for me.

-Paul

On May 15, 2015 10:03 AM, Murphy, Grant 
grant.mur...@hp.commailto:grant.mur...@hp.com wrote:
At the last OSSG mid-cycle a number of us put together some security guidelines 
and best practices aimed at developers. We are now attempting to migrate this 
content to the https://security.openstack.org page. However we need to come to 
agreement on how to license this content.  I’m proposing that we move from an 
Apache license to CC-BY as per Jeremy’s comments in this review 
https://review.openstack.org/#/c/181123/.  Do any of the original authors 
(listed below) have an objection to this?

Authors:
  Dave Belcher (HP)
  Doug Chivers (HP)
  Lucas Fisher (Was Nebula)
  Grant Murphy (HP)
  Rob Clarke (HP)
  Travis McPeak (HP)
  Tim Kelsey (HP)
  Eric Brown (VMWare)
  Brant Knudson (IBM)
  Paul McMillan (Was Nebula)
  Rob Fletcher (Uber)
  Nathaniel Dillon (HP)
  Jamie Finnigan (HP)

- Grant


__
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] [Security] Reminder - No IRC meeting this week

[Clark, Robert Graham]

Just a quick reminder, the security project IRC meeting is cancelled this week 
so we can be ready for the summit.

-Rob

__
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] [Security] CORS Documentation

[Clark, Robert Graham]

Hi Michael,



Nathaniel might have some insight here, adding him directly.



Cheers

-Rob



From: Michael Krotscheck [mailto:krotsch...@gmail.com]
Sent: 05 May 2015 16:33
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Security] CORS Documentation



Hey everyone!



I'm currently managing an OpenStack specification to introduce CORS support to 
Liberty.  The specification is here for your review: 
https://review.openstack.org/#/c/179866/1



Seeing as activating CORS has security implications, I strongly feel that the 
documentation should reflect this, and at Anne Gentle's suggestion I'd like 
some suggestions on where this might live. It will definitely live in the Cloud 
Admin guide - are there any other places where I should make a point to 
highlight these issues?



Michael

__
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] [Security] Design Summit Sessions

[Clark, Robert Graham]

Hi Security,

We have two fishbowl events and one boardroom, I’ve assigned them to activities:

[Fishbowl] 20 May, 1350, Vulnerability Management
[Boardroom] 21 May, 0950, Security: Work Session [Rebranding]
[Fishbowl] 21 May, 1700, Security Tooling

Please take a look at the link below and let me know if there are any suggested 
changes

http://libertydesignsummit.sched.org/type/design+summit/Security#.VToWqRPF_8k

__
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] [Security] Meeting agenda

[Clark, Robert Graham]

Reminder to all, our meeting is today at 1700 UTC on Freenode 
#openstack-meeting-alt

The agenda can be found here: 
https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity#Agenda_for_next_meeting

* Roll Call
* Reminder that the agenda exists
* Update on project status
* security.openstack.org
** Potential as a home for OSSN
** Potential as a home for Developer Security Guidelines
** Security Blog
*OpenStack Security Guide
* Previous Action: nkinder to review sec guide identity section (tmcpeak, 
17:23:33)
* Previous Action: shelleea007 to review sec guide network section
* Update
* Open Bugs Requiring Review
* OpenStack Summit
** Developer space / fish bowls
** Entitlement organisation
* OSSN YAML Update
* Elections
** Changes to election terms
** Doing things the OpenStack way

-Rob

__
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] Announcement - The Security Team for OpenStack

[Clark, Robert Graham]

The OpenStack Security Group (OSSG) and the OpenStack Vulnerability Management
Team (VMT) have historically operated as independent teams, each with a focus on
different aspects of OpenStack security. To present a more coherent security
posture we are pleased to announce that the OSSG and VMT will be joining forces.

It is our hope that this merging of teams will help present a stronger and more
mature security posture, both to the outside world and within OpenStack, and
will make it easier for developers to engage with the security resources they
need.

Moving forward, the OSSG and VMT combined will apply to become a recognized
project within OpenStack. We seek to mirror the successes of the documentation
team and will be applying to become known simply as 'Security'.

We are excited about the new opportunities this creates and are hopeful that it
gives OpenStack a clearer security message.

What is changing? 

Initially a huge work effort will be undertaken to restructure and rebrand
existing documentation which will eventually be hosted under a new subdomain of
openstack.org [1]. This will allow developers and consumers of OpenStack to
easily find security resources such as the OpenStack Security Advisories, the
Security Guide, Security Notes and Best Practices.

Does this change how I report security issues? 

No. The existing vulnerability management process [2], and team members will
remain the same. The VMT will maintain its independence and will continue to
operate with the same level of confidentiality as before. 

How can I get involved? 

The security group is always looking for enthusiastic new members; there's a
wiki article on how to get involved[3]. If you are interested, please come along
to the weekly IRC meeting, or just start contributing.

Asking the security group questions? 

Any general security questions that do not relate to a vulnerability within the
OpenStack code base should be sent to the openstack-dev@lists.openstack.org
address with the [security] in the subject line.


1. https://security.openstack.org
2. https://wiki.openstack.org/wiki/Vulnerability_Management
3. https://wiki.openstack.org/wiki/Security/How_To_Contribute

__
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] [tc] Request to adopt security as a project team

[Clark, Robert Graham]

Technical Committee,

Please consider this request to recognize the security team as an OpenStack
project team.

This is a milestone for the OpenStack Security Group and follows from our
merging with the VMT. Over the last few years what started as a small working
group has become a team of dedicated security experts who assist with security
advisories, create security notes and developer guidance. We've created
technologies and tools such as ephemeral PKI (Anchor) and Python static
analysis to help the community to build more secure services.

Following the new project team application process, we request that the
technical committee consider our application to become a recognised OpenStack
project team:

https://review.openstack.org/170172

Thank You.

-Rob

__
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] [Security] Agenda for next meeting

[Clark, Robert Graham]

Security folks,

The agenda for the next security group meeting is up on
https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity#OpenStack_Security_Group_Meetings

As a reminder, this is 1700 UTC on irc.freenode.net #openstack-meeting-alt

Cheers
-Rob

__
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] [OSSG] Announcement: I'll be transitioning away from OpenStack

[Clark, Robert Graham]

This is a big loss to the community, it’s been a real pleasure working with you 
over the last three years and I wish you all the best in the future!

 

-Rob

 

From: Bryan D. Payne [mailto:bdpa...@acm.org] 
Sent: 16 March 2015 21:53
To: OpenStack Development Mailing List
Subject: [openstack-dev] [OSSG] Announcement: I'll be transitioning away from 
OpenStack

 

I have recently accepted a new position with a company that does not work with 
OpenStack.  As a result, I'll be transitioning away from this community.  As 
such, I wanted to offer a few quick notes:

 

* OpenStack Security Guide -- I have transitioned leadership of this security 
documentation effort to Nathaniel Dillon.

 

* #openstack-security IRC channel -- Travis McPeak now also has OP privilege in 
the channel.

 

Beyond that, I just wanted to say thanks to everyone.  The OpenStack community 
has been great to work with over the past several years and I wish you all the 
best in the time ahead!

 

I have about one more week working with OpenStack full time.  After that, I am 
still planning on coming to the summit in May, and would be happy to help with 
any final transition pieces at that time.  And I'll continue being available at 
this email address well into the future.

 

Cheers,

-bryan



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

Re: [openstack-dev] nominating Nathaniel Dillon for security-doc core

[Clark, Robert Graham]

On 05/03/2015 21:37, Nathan Kinder nkin...@redhat.com wrote:



On 03/05/2015 01:14 PM, Bryan D. Payne wrote:
 To security-doc core and other interested parties,
 
 Nathaniel Dillon has been working consistently on the security guide
 since our first mid-cycle meet up last summer.  In that time he has come
 to understand the inner workings of the book and the doc process very
 well.  He has also been a consistent participant in improving the book
 content and working to define what the book should be going forward.
 
 I'd like to bring him on as a core member of security-doc so that he can
 help with the review and approval process for new changes to the book.
 Please chime in with your agreement or concerns.

+1 on making Nathaniel core!

-NGK

 
 Cheers,
 -bryan

+1 Excellent idea.


__
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] Lack of quota - security bug or not?

[Clark, Robert Graham]

On 11/12/2014 13:16, Thierry Carrez thie...@openstack.org wrote:


George Shuklin wrote:
 
 
 On 12/10/2014 10:34 PM, Jay Pipes wrote:
 On 12/10/2014 02:43 PM, George Shuklin wrote:
 I have some small discussion in launchpad: is lack of a quota for
 unprivileged user counted as security bug (or at least as a bug)?

 If user can create 100500 objects in database via normal API and ops
 have no way to restrict this, is it OK for Openstack or not?

 That would be a major security bug. Please do file one and we'll get
 on it immediately.

 
 (private bug at that moment)
https://bugs.launchpad.net/ossa/+bug/1401170
 
 There is discussion about this. Quote:
 
 Jeremy Stanley (fungi):
 Traditionally we've not considered this sort of exploit a security
 vulnerability. The lack of built-in quota for particular kinds of
 database entries isn't necessarily a design flaw, but even if it
 can/should be fixed it's likely not going to get addressed in stable
 backports, is not something for which we would issue a security
 advisory, and so doesn't need to be kept under secret embargo. Does
 anyone else disagree?
 
 If anyone have access to OSSA tracker, please say your opinion in that
bug.

It also depends a lot on the details. Is there amplification ? Is there
a cost associated ? I bet most public cloud providers would be fine with
a user creating and paying for running 100500 instances, and that user
would certainly end up creating at least 100500 objects in database via
normal API.

So this is really a per-report call, which is why we usually discuss
them all separately.

-- 
Thierry Carrez (ttx)

Most public cloud providers would not be in any way happy with a new
customer spinning up anything like that number of instances. Fraud and
Abuse are major concerns for public cloud providers. Automated checks take
time.

Imagine someone using a stolen but not yet cancelled credit card spinning
up 1000¹s of instances. The card checks out ok when the user signs up but
has been cancelled by the time the billing cycle closes - massive loss to
the cloud provider in at least three ways. Direct lost revenue from that
customer,  the loss of capacity which possibly stopped other customers
bringing business to the platform and finally the likelyhood that the
account was setup for malicious purposes, either internet facing or
against the cloud infrastructure itself.

Please add me to the bug if you¹d like to discuss further.

-Rob


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-security] [Barbican][OSSG] Mid Cycle Attendance / Crossover.

[Clark, Robert Graham]

Sounds like a security/identity/secrets mashup might be on the cards  – should 
be fun!

-Rob

From: Morgan Fainberg 
morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 11 November 2014 21:52
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-security] [Barbican][OSSG] Mid Cycle 
Attendance / Crossover.


On Nov 11, 2014, at 1:45 PM, Lance Bragstad 
lbrags...@gmail.commailto:lbrags...@gmail.com wrote:



On Tue, Nov 11, 2014 at 3:30 PM, Douglas Mendizabal 
douglas.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com 
wrote:
I think it would also be interesting to hear for the Keystone folks that
are interested in attending OSSG and/or Barbican.

We did record some of our plans for the Keystone mid-cycle meetup during our 
last session
at the summit [1]. I don't think we have any specifics set in stone yet though. 
Maybe we could hash
it out during one of the project meetings next week if people are interested?


[1] https://etherpad.openstack.org/p/kilo-keystone-meetup


I’ve just updated the ether pad with some details. I expect to send an email 
out to the ML re the mid-cycle in the next day or so (for coordination 
purposes).
Is there currently a (even tentative) plan for Barbican?

—Morgan

  A few people have told
me they found the Keystone/Barbican overlap for the last mid-cycle to be
helpful, so it might be worthwhile doing again.

-Doug M.


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C




On 11/7/14, 8:02 PM, Clark, Robert Graham 
robert.cl...@hp.commailto:robert.cl...@hp.com wrote:

Hi All,

How many people would want to attend both the OSSG mid-cycle and the
Barbican one? Both expected to be on the west coast of the US.

We are trying to work out how/if we should organise these events to take
place at adjacent times and if they should be in the same location, back
to back to reduce travel costs.

Cheers
-Rob


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican][OSSG] Mid Cycle Attendance / Crossover.

[Clark, Robert Graham]

Hi All,

How many people would want to attend both the OSSG mid-cycle and the Barbican 
one? Both expected to be on the west coast of the US.

We are trying to work out how/if we should organise these events to take place 
at adjacent times and if they should be in the same location, back to back to 
reduce travel costs.

Cheers
-Rob


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Is there an agreed way for plugins to log output

[Clark, Robert Graham]

As above, couldn’t see any conventions.

Thanks
-Rob


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Etherpad discussion related to ssl certificate workflow CR

[Clark, Robert Graham]

We’ve been looking into CA’s that give you an instant response on a certificate 
signing request (based on various conditions) - I’m not sure that we can easily 
make this work with the state structures described?

Our basic flow is
Client —[https|somecreds|some https://somecreds|somecsr]-- CA
Client —[https|certificate/error400]—CA

The CA does a lot of stuff in the backend but for the purposes of this the 
decision about making the cert is instant, there’s no ‘queue’ to wait on. It’s 
not immediately clear to me if there’s some option to shortcut the states laid 
out to make a plugin work nicely with our prototype CA…

Cheers
-Rob

From: John Wood john.w...@rackspace.commailto:john.w...@rackspace.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, 17 July 2014 15:37
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: barbi...@lists.rackspace.commailto:barbi...@lists.rackspace.com 
barbi...@lists.rackspace.commailto:barbi...@lists.rackspace.com
Subject: [openstack-dev] [barbican] Etherpad discussion related to ssl 
certificate workflow CR

Hello folks,

Ade raised concerns about the approach taken in the SSL cert CR here: 
https://review.openstack.org/#/c/107190/

In short, he suggests that a state machine approach that gives plugins a lot of 
control over workflow is not needed, and could lead to plugin developers having 
more difficulty creating new plugins. I think he has valid points, so I created 
an etherpad that details a 'generic' workflow approach, and an approach that 
simplifies what the plugins need to do (offloading logic to Barbican): 
https://etherpad.openstack.org/p/barbican-order-cert-gen-interactions

Please take a look at the etherpad and weigh in if you can.

Thanks,
John



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Barebones CA

[Clark, Robert Graham]

Just a quick update on this, I started work on a basic plugin but quickly
found I was running out of time.

I handed over to Tim Kelsey, who had a few concerns about the plumbing
required to make this work, I’ve CC’d him on this thread.

-Rob





On 28/06/2014 08:03, John Wood john.w...@rackspace.com wrote:

Hello folks,

Just trying clarify things...are we talking about a dev plugin to
generate asymmetric keys, or else one to mimic working with a CA to
create SSL certificates via workflow (so including firing off
certificate-generated events, for example)?

If we are talking about the former, then you would be interested in a
plugin that implements a method such as this one:
https://github.com/openstack/barbican/blob/master/barbican/plugin/interfac
e/secret_store.py#L167

If you are talking about the latter, then that would be a different type
of plugin that handles CA workflows, as proposed in this blueprint:
https://review.openstack.org/#/c/99221/

Thanks,
John


From: Nathan Kinder [nkin...@redhat.com]
Sent: Wednesday, June 25, 2014 9:43 PM
To: OpenStack Development Mailing List (not for usage questions);
a...@redhat.com
Subject: Re: [openstack-dev] [Barbican] Barebones CA

On 06/25/2014 02:42 PM, Clark, Robert Graham wrote:

 Ok, I’ll hack together a dev plugin over the next week or so, other work
 notwithstanding. Where possible I’ll probably borrow from the dog tag
 plugin as I’ve not looked closely at the plugin infrastructure in
Barbican
 recently.

My understanding is that Barbican's plugin interface is currently in the
midst of a redesign, so be careful not to copy something that will be
changing shortly.

-NGK


 Is this something you’d like a blueprint for first?

 -Rob




 On 25/06/2014 18:30, Ade Lee a...@redhat.com wrote:

 I think the plan is to create a Dogtag instance so that integration
 tests can be run whenever code is checked in (both with and without a
 Dogtag backend).

 Dogtag isn't that difficult to deploy, but being a Java app, it does
 bring in a set of dependencies that developers may not want to deal
with
 for basic/ devstack testing.

 So, I agree that a simple OpenSSL CA may be useful at least initially
as
 a 'dev' plugin.

 Ade

 On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote:
 Rob,

 RedHat is working on a backend for Dogtag, which should be capable of
 doing something like that. That's still a bit hard to deploy, so it
 would
 make sense to extend the 'dev' plugin to include those features.


 Jarret


 On 6/24/14, 4:04 PM, Clark, Robert Graham robert.cl...@hp.com
wrote:

 Yeah pretty much.

 That¹s something I¹d be interested to work on, if work isn¹t ongoing
 already.

 -Rob





 On 24/06/2014 18:57, John Wood john.w...@rackspace.com wrote:

 Hello Robert,

 I would actually hope we have a self-contained certificate plugin
 implementation that runs 'out of the box' to enable certificate
 generation orders to be evaluated and demo-ed on local boxes.

 Is this what you were thinking though?

 Thanks,
 John



 
 From: Clark, Robert Graham [robert.cl...@hp.com]
 Sent: Tuesday, June 24, 2014 10:36 AM
 To: OpenStack List
 Subject: [openstack-dev] [Barbican] Barebones CA

 Hi all,

 I¹m sure this has been discussed somewhere and I¹ve just missed it.

 Is there any value in creating a basic ŒCA¹ and plugin to satisfy
 tests/integration in Barbican? I¹m thinking something that probably
 performs OpenSSL certificate operations itself, ugly but perhaps
 useful
 for some things?

 -Rob

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Barbican] Barebones CA

[Clark, Robert Graham]

On 26/06/2014 03:43, Nathan Kinder nkin...@redhat.com wrote:



On 06/25/2014 02:42 PM, Clark, Robert Graham wrote:
 
 Ok, I’ll hack together a dev plugin over the next week or so, other work
 notwithstanding. Where possible I’ll probably borrow from the dog tag
 plugin as I’ve not looked closely at the plugin infrastructure in
Barbican
 recently.

My understanding is that Barbican's plugin interface is currently in the
midst of a redesign, so be careful not to copy something that will be
changing shortly.

-NGK

Good point, thanks Nathan, I’ll try to keep the ‘do-poi-stuff’ bit nicely
decoupled from the ‘barbican’ bit.


 
 Is this something you’d like a blueprint for first?
 
 -Rob
 
 
 
 
 On 25/06/2014 18:30, Ade Lee a...@redhat.com wrote:
 
 I think the plan is to create a Dogtag instance so that integration
 tests can be run whenever code is checked in (both with and without a
 Dogtag backend).

 Dogtag isn't that difficult to deploy, but being a Java app, it does
 bring in a set of dependencies that developers may not want to deal
with
 for basic/ devstack testing.

 So, I agree that a simple OpenSSL CA may be useful at least initially
as
 a 'dev' plugin.

 Ade

 On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote:
 Rob,

 RedHat is working on a backend for Dogtag, which should be capable of
 doing something like that. That's still a bit hard to deploy, so it
 would
 make sense to extend the 'dev' plugin to include those features.


 Jarret


 On 6/24/14, 4:04 PM, Clark, Robert Graham robert.cl...@hp.com
wrote:

 Yeah pretty much.

 That¹s something I¹d be interested to work on, if work isn¹t ongoing
 already.

 -Rob





 On 24/06/2014 18:57, John Wood john.w...@rackspace.com wrote:

 Hello Robert,

 I would actually hope we have a self-contained certificate plugin
 implementation that runs 'out of the box' to enable certificate
 generation orders to be evaluated and demo-ed on local boxes.

 Is this what you were thinking though?

 Thanks,
 John



 
 From: Clark, Robert Graham [robert.cl...@hp.com]
 Sent: Tuesday, June 24, 2014 10:36 AM
 To: OpenStack List
 Subject: [openstack-dev] [Barbican] Barebones CA

 Hi all,

 I¹m sure this has been discussed somewhere and I¹ve just missed it.

 Is there any value in creating a basic ŒCA¹ and plugin to satisfy
 tests/integration in Barbican? I¹m thinking something that probably
 performs OpenSSL certificate operations itself, ugly but perhaps
 useful
 for some things?

 -Rob

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]One security issue about floating ip

[Clark, Robert Graham]

It¹s kinda ugly, if a user through API/Horizon thinks they¹ve isolated a
host, it should be isolatedŠ

I smell an OSSN here...

On 26/06/2014 17:57, Miguel Angel Ajo Pelayo mangel...@redhat.com
wrote:

Yes, once a connection has past the nat tables,
and it's on the kernel connection tracker, it
will keep working even if you remove the nat rule.

Doing that would require manipulating the kernel
connection tracking to kill that connection,
I'm not familiar with that part of the linux network
stack, not sure if it's possible, but that would be
the perfect way. (kill nat connection on ext ip=float ip int_ip =
internal ip)...




- Original Message -
 Hi folks,
 
 After we create an SSH connection to a VM via its floating ip, even
though we
 have removed the floating ip association, we can still access the VM via
 that connection. Namely, SSH is not disconnected when the floating ip
is not
 valid. Any good solution about this security issue?
 
 Thanks
 Xurong Yang
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Barebones CA

[Clark, Robert Graham]

Ok, I’ll hack together a dev plugin over the next week or so, other work
notwithstanding. Where possible I’ll probably borrow from the dog tag
plugin as I’ve not looked closely at the plugin infrastructure in Barbican
recently.

Is this something you’d like a blueprint for first?

-Rob




On 25/06/2014 18:30, Ade Lee a...@redhat.com wrote:

I think the plan is to create a Dogtag instance so that integration
tests can be run whenever code is checked in (both with and without a
Dogtag backend).

Dogtag isn't that difficult to deploy, but being a Java app, it does
bring in a set of dependencies that developers may not want to deal with
for basic/ devstack testing.

So, I agree that a simple OpenSSL CA may be useful at least initially as
a 'dev' plugin.

Ade

On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote:
 Rob,
 
 RedHat is working on a backend for Dogtag, which should be capable of
 doing something like that. That's still a bit hard to deploy, so it
would
 make sense to extend the 'dev' plugin to include those features.
 
 
 Jarret
 
 
 On 6/24/14, 4:04 PM, Clark, Robert Graham robert.cl...@hp.com wrote:
 
 Yeah pretty much.
 
 That¹s something I¹d be interested to work on, if work isn¹t ongoing
 already.
 
 -Rob
 
 
 
 
 
 On 24/06/2014 18:57, John Wood john.w...@rackspace.com wrote:
 
 Hello Robert,
 
 I would actually hope we have a self-contained certificate plugin
 implementation that runs 'out of the box' to enable certificate
 generation orders to be evaluated and demo-ed on local boxes.
 
 Is this what you were thinking though?
 
 Thanks,
 John
 
 
 
 
 From: Clark, Robert Graham [robert.cl...@hp.com]
 Sent: Tuesday, June 24, 2014 10:36 AM
 To: OpenStack List
 Subject: [openstack-dev] [Barbican] Barebones CA
 
 Hi all,
 
 I¹m sure this has been discussed somewhere and I¹ve just missed it.
 
 Is there any value in creating a basic ŒCA¹ and plugin to satisfy
 tests/integration in Barbican? I¹m thinking something that probably
 performs OpenSSL certificate operations itself, ugly but perhaps
useful
 for some things?
 
 -Rob
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Barebones CA

[Clark, Robert Graham]

Hi all,

I’m sure this has been discussed somewhere and I’ve just missed it.

Is there any value in creating a basic ‘CA’ and plugin to satisfy 
tests/integration in Barbican? I’m thinking something that probably performs 
OpenSSL certificate operations itself, ugly but perhaps useful for some things?

-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Barebones CA

[Clark, Robert Graham]

Yeah pretty much.

That¹s something I¹d be interested to work on, if work isn¹t ongoing
already.

-Rob





On 24/06/2014 18:57, John Wood john.w...@rackspace.com wrote:

Hello Robert,

I would actually hope we have a self-contained certificate plugin
implementation that runs 'out of the box' to enable certificate
generation orders to be evaluated and demo-ed on local boxes.

Is this what you were thinking though?

Thanks,
John




From: Clark, Robert Graham [robert.cl...@hp.com]
Sent: Tuesday, June 24, 2014 10:36 AM
To: OpenStack List
Subject: [openstack-dev] [Barbican] Barebones CA

Hi all,

I¹m sure this has been discussed somewhere and I¹ve just missed it.

Is there any value in creating a basic ŒCA¹ and plugin to satisfy
tests/integration in Barbican? I¹m thinking something that probably
performs OpenSSL certificate operations itself, ugly but perhaps useful
for some things?

-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Periodic Security Checks

[Clark, Robert Graham]

I think this is very interesting and would love to see the code for it.

The blueprint mentions performing checks beyond what Open Attestation
provides, add dynamic check to verify memory - this is probably a
stretch goal as process memory verification is extremely complex. I'm
not aware of anyone doing it well though I'd love to be corrected on
that point. I also wonder how, if working outside of Open Attestation
(and I'm assuming outside of TPM) how you will assert that attestations
are accurate.

I'm sure the intel guys will have a lot to contribute here and I'm
excited to see people working to improve Compute security with cool
projects such as this one.

-Rob



 -Original Message-
 From: Grant Murphy [mailto:gmur...@redhat.com]
 Sent: 23 June 2014 00:49
 To: OpenStack Development Mailing List (not for usage questions);
 openstack-secur...@lists.openstack.org
 Cc: Vasiliy Artemev; David Yuan
 Subject: Re: [Openstack-security] [openstack-dev] Periodic Security
Checks
 
 Adding openstack-security to the thread. In case folks on OSSG don't
 monitor this list.
 
 - Original Message -
  From: Alexandr Naumchev anaumc...@gmail.com
  To: openstack-dev@lists.openstack.org
  Cc: Amey Ghadigaonkar gamoholic...@gmail.com, Vasiliy Artemev
 vas...@gmail.com, David Yuan
  david.yuanh...@gmail.com
  Sent: Sunday, June 22, 2014 4:33:35 AM
  Subject: [openstack-dev] Periodic Security Checks
 
  Hello!
  We have blueprints here:
 
 
https://blueprints.launchpad.net/horizon/+spec/periodic-security-check
  s
 
  and here:
 
 
https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/
 
  And we already have some code. Is it necessary to approve the
  blueprint before contributing the code? In any case, could someone
  review the aforementioned blueprints?
  Thanks!
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 Openstack-security mailing list
 openstack-secur...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Mid-Cycle Meetup

[Clark, Robert Graham]

Thanks Jamie,

Due to timing issues we've decided to host the OSSG mid-cycle separate from the 
Keystone/Barbican one - though it's worth noting that a lot of our interests 
overlap.

We are actually covering a bunch of interesting ground and anyone security 
oriented is welcome to attend.

https://etherpad.openstack.org/p/ossg-juno-meetup

Likewise I'm assured that OSSG folks can tag along at the Barbican meetup if 
they're available.

-Rob


 -Original Message-
 From: Jamie Lennox [mailto:jamielen...@redhat.com]
 Sent: 13 June 2014 03:55
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Openstack-security]
 [Barbican][OSSG][Keystone] Mid-Cycle Meetup
 
 
 
 - Original Message -
  From: Jamie Lennox jamielen...@redhat.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Sent: Friday, June 13, 2014 12:28:25 PM
  Subject: Re: [openstack-dev] [Openstack-security]
  [Barbican][OSSG][Keystone] Mid-Cycle Meetup
 
  On Thu, 2014-06-12 at 16:29 -0700, Valerie Anne Fenwick wrote:
   Hi FOlks
  
   I haven't seen anymore on this. Is this happening?  If so, are there
   more details? (location, agenda, etc).  Thanks!
 
  Details: http://dolphm.com/openstack-keystone-hackathon-for-juno/
 
  I think the agenda will be pushing forward and follow up from things
  decided at the summit and generally getting things done (so nothing
  formal).
 
 Note: that this is the keystone part of it and my understanding is that
 barbican is happening in conjunction.
 Details for the OSSG one are here: https://etherpad.openstack.org/p/ossg-
 juno-meetup
 
 
   Valerie
  
   On 05/23/14 06:26 AM, Adam Young wrote:
The Keystone team  is going to be making sure the  code that needs
to be in by J2 is in.  That means the API changes.
   
I'll be there.
   
   
On 05/23/2014 03:09 AM, Clark, Robert Graham wrote:
I’d like to attend all the Barbican stuff and I’m sure there’ll
be some interesting Keystone things too.
   
I think it’s likely we’d do more parallel ‘OSSG’ stuff on the
Keystone days though
   
I’m free on these dates.
   
From: Bryan Payne bdpa...@acm.orgmailto:bdpa...@acm.org
Date: Friday, 23 May 2014 02:14
To: Jarret Raim
   
 jarret.r...@rackspace.commailto:jarret.r...@rackspace.com
Cc:
openstack-secur...@lists.openstack.orgmailto:openstack-
 secur...@lists.openstack.org
openstack-secur...@lists.openstack.orgmailto:openstack-security
@lists.openstack.org,
OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-
 d...@lists.ope
nstack.org
Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone]
Mid-Cycle Meetup
   
I plan on attending.
-bryan
   
   
On Thu, May 22, 2014 at 10:48 AM, Jarret Raim
jarret.r...@rackspace.commailto:jarret.r...@rackspace.com
 wrote:
All,
   
There was some interest at the Summit in semi-combining the
mid-cycle meet ups for Barbican, Keystone and the OSSG as there
is some overlap in team members and interest areas. The current
dates being considered are:
   
Mon, July 7 - Barbican
Tue, July 8 - Barbican
Wed, July 9 - Barbican / Keystone Thu, July 10 - Keystone Fri,
July 11 - Keystone
   
Assuming these dates work for for everyone, we'll fit some OSSG
work in during whatever days make the most sense. The current
plan is to have the meet up in San Antonio at the new Geekdom
location, which is downtown.
This should make travel a bit easier for everyone as people won't
need cars are there are plenty of hotels and restaurants within
walking / short cab distance.
   
I wanted to try to get a quick head count from the Barbican and
OSSG folks (I think Dolph already has one for Keystone). I'd also
like to know if you are a Barbican person interested in going to
the Keystone sessions or vice versa.
   
Once we get a rough head count estimate, Dolph and I can work on
getting everything booked.
   
   
   
   
   
Thanks,
   
--
Jarret Raim
@jarretraim
   
   
   
___
Openstack-security mailing list
openstack-secur...@lists.openstack.orgmailto:Openstack-
 security@
lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sec
urity
   
   
   
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   
   
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin

Re: [openstack-dev] Message level security plans. [barbican]

[Clark, Robert Graham]

 -Original Message-
 From: Jamie Lennox [mailto:jamielen...@redhat.com]
 Sent: 13 June 2014 03:25
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Message level security plans. [barbican]
 
 On Thu, 2014-06-12 at 23:22 +, Tiwari, Arvind wrote:
  Thanks Nathan for your response.
 
  Still not very convinced for two separate service.
 
  Keystone authentication is not a mandatory requirement for Barbican,
as
 per design it can work without Keystone authentication. Rest
(temporary
 session key generation, long-term keys ...) are feature gap which can
be
 easily developed in barbican.
 
  If Barbican has to store long term keys on behalf of Kite users than
IMO it
 is good to merge these two services. We can develop separate plug-in
to
 achieve KDC (or Kite plug-in). One can have two separate barbican
 deployments one of KDC another for KMS (or may be only one with
 enhanced barbican API).
 
  Thoughts?
 
 I think you're looking at the wrong part of the stack here. Barbican
is a user
 facing component, kite is looking at securing messages between
services
 that are sent over a message bus. They will need to be deployed and
 configured in a completely different manner. The users in this case
are host
 machines.
 
 I don't think that session key generation is a 'gap' in barbican's
features, I
 think it's very correctly outside of scope. Key generation such as
this is done
 in a very specific format for a very specific use case, and includes a
lot of
 metadata that has no application outside of kite.
 
 Kite or a KDC plugin, would still need to manage a whole lot of state
around
 services and which services can talk to which other services.
 This is very much outside barbican's scope.
 
 The only thing that is really common between the two projects is
safely
 storing encrypted keys, and even then a fundamental purpose of
barbican is
 being able to retrieve the keys, which kite should never do. So we
would
 then need to start putting things into barbican to mark these keys as
 special...
 
 This was discussed at the summit (you were in that room) that when
 appropriate we should look at having an option for kite to use
barbican for
 it's long term key storage and look to extract the secure key storage
 component from barbican (or kite) into a library that can be shared
between
 the two components if feasible.
 
 In summary, yes they both store keys but the plugin you suggest will
end up
 with the same API surface area as barbican itself, involve a lot of
service
 management that is way outside of barbican's scope, will need to scale
for
 a different reason, will need to be discovered by a different class of
user
 and have different requirements on 'privacy' on keys.
 
 Why would we want to deal with all that if you would still need
another
 barbican deployment?
 
 
 Jamie
 

I feel that we did a good job of discussing this at the summit and there
was a strong consensus that Kite is very distinct from Barbican, it
fulfils different use cases and operates at a different level of the
stack. To my mind conceptually lumping Kite together with Barbican is as
confusing as throwing it in with keystone because that handles user
credentials, different tools for different jobs.

-Rob


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Calling on Security Engineers / Developers / Architects - Time to share your toys

[Clark, Robert Graham]

All,

TL:DR; Lets work together and openly on security review and threat
analysis for OpenStack

I've discussed this for a while within the security group but now I'm
sharing more widely here on -dev. 

There are currently scores of security reviews taking place on OpenStack
architecture, projects and implementations. All the big players in
OpenStack are conducting their own security reviews, we are all finding
things that should be addressed in the community and I'm sure that we
are all missing things that others have found too.

There's very little commercial value in holding onto security review
data. I am, appealing to the security people out there in the community
to come together and share expertise on Threat Modelling/Analysis in
OpenStack. There's already been some excellent path-finding here (
https://wiki.openstack.org/wiki/Security/Threat_Analysis ).

My long term aspiration is that Threat Analysis and Penetration Testing
eventually gets performed in the open, in a collaborative process
between several organisations, all finding issues, opening bugs and
submitting patches together. With each organisation performing internal
audits on their deltas for secret source / value added stuff. I believe
by doing this we can raise the bar on all of our collective security
efforts while decreasing the massive duplication of effort that's going
on right now.

The security group is having a mid-cycle sprint in July, we are looking
to cover a lot of ground (
https://etherpad.openstack.org/p/ossg-juno-meetup ) but one of the
primary topics we will be focussing on is the Threat Modelling process.
How it can be shaped and how it should move forward. I hope that some of
you can be there and if not, that we can get the sharing and
collaboration of security reviews onto the security agenda at your
respective organisations. 

Cheers
-Rob




 



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

[Clark, Robert Graham]

Users have to be able to delete their secrets from Barbican, it's a
fundamental key-management requirement.

 -Original Message-
 From: Eichberger, German
 Sent: 11 June 2014 17:43
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit
 
 Sorry, I am late to the party. Holding the shadow copy in the backend
is a
 fine solution.
 
 Also, if containers are immutable can they be deleted at all? Can we
make a
 requirement that a user can't delete a container in Barbican?
 
 German
 
 -Original Message-
 From: Eichberger, German
 Sent: Wednesday, June 11, 2014 9:32 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit
 
 Hi,
 
 I think the previous solution is easier for a user to understand. The
 referenced container got tampered/deleted we throw an error - but keep
 existing load balancers intact.
 
 With the shadow container we get additional complexity and the user
might
 be confused where the values are coming from.
 
 German
 
 -Original Message-
 From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
 Sent: Tuesday, June 10, 2014 12:18 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document
 on Gerrit
 
 See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican
 Neutron LBaaS Integration Ideas.
 He's advocating keeping a shadow copy of the private key that is owned
by
 the LBaaS service so that incase a key is tampered with during an LB
update
 migration etc we can still check with the shadow backup and compare it
to
 the user owned TLS container in case its not their it can be used.
 
 On Jun 10, 2014, at 12:47 PM, Samuel Bercovici samu...@radware.com
  wrote:
 
  To elaborate on the case where containers get deleted while LBaaS
still
 references it.
  We think that the following approach will do:
  * The end user can delete a container and leave a dangling
 reference in LBaaS.
  * It would be nice to allow adding meta data on the
container so that
 the user will be aware which listeners use this container. This is
optional. It
 can also be optional for LBaaS to implement adding the listeners ID
 automatically into this metadata just for information.
  * In LBaaS, if an update happens which requires to pull the
container
 from Barbican and if the ID references a non-existing container, the
update
 will fail and will indicate that the reference certificate does not
exists any
 more. This validation could be implemented on the LBaaS API itself as
well
 as also by the driver who will actually need the container.
 
  Regards,
  -Sam.
 
 
  From: Evgeny Fedoruk
  Sent: Tuesday, June 10, 2014 2:13 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST
document
  on Gerrit
 
  Hi All,
 
  Carlos, Vivek, German, thanks for reviewing the RST doc.
  There are some issues I want to pinpoint final decision on them
here, in
 ML, before writing it down in the doc.
  Other issues will be commented on the document itself.
 
  1.   Support/No support in JUNO
  Referring to summit's etherpad
 https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7,
  a.   SNI certificates list was decided to be supported. Was
decision made
 not to support it?
  Single certificate with multiple domains can only partly address the
  need for SNI, still, different applications on back-end will need
different
 certificates.
  b.  Back-end re-encryption was decided to be supported. Was
decision
 made not to support it?
  c.   With front-end client authentication and back-end server
 authentication not supported,
  Should certificate chains be supported?
  2.   Barbican TLS containers
  a.   TLS containers are immutable.
  b.  TLS container is allowed to be deleted, always.
 i.
Even when it is used by LBaaS VIP
 listener (or other service).
   ii.
Meta data on TLS container will
 help tenant to understand that container is in use by LBaaS
service/VIP
 listener
  iii.
If every VIP listener will register
 itself in meta-data while retrieving container, how that
registration will be
 removed when VIP listener stops using the certificate?
 
  Please comment on these points and review the document on gerrit
  (https://review.openstack.org/#/c/98640)
  I will update the document with decisions on above topics.
 
  Thank you!
  Evgeny
 
 
  From: Evgeny Fedoruk
  Sent: Monday, June 09, 2014 2:54 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [Neutron][LBaaS] TLS support 

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[Clark, Robert Graham]

It looks like this has come full circle and we are back at the simplest case.

# Containers are immutable
# Changing a cert means creating a new container and, when ready, pointing 
LBaaS at the new container

This makes a lot of sense to me, it removes a lot of handholding and keeps 
Barbican and LBaaS nicely decoupled. It also keeps certificate lifecycle 
management firmly in the hands of the user, which imho is a good thing. With 
this model it’s fairly trivial to provide guidance / additional tooling for 
lifecycle management if required but at the same time the simplest case (I want 
a cert and I want LBaaS) is met without massive code overhead for edge-cases.


From: Vijay Venkatachalam 
vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 10 June 2014 05:48
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas


My vote is for option #2 (without the registration). It is simpler to start 
with this approach. How is delete handled though?

Ex. What is the expectation when user attempts to delete a 
certificate/container which is referred by an entity like LBaaS listener?


1.   Will there be validation in Barbican to prevent this? *OR*

2.   LBaaS listener will have a dangling reference/pointer to certificate?

Thanks,
Vijay V.

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, June 10, 2014 7:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

Weighing in here:

I'm all for option #2 as well.

Stephen

On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum 
cl...@fewbar.commailto:cl...@fewbar.com wrote:
Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700:
 Hi all,

 I’m strongly in favor of having immutable TLS-typed containers, and very
 much opposed to storing every revision of changes done to a container.  I
 think that storing versioned containers would add too much complexity to
 Barbican, where immutable containers would work well.

Agree completely. Create a new one for new values. Keep the old ones
while they're still active.


 I’m still not sold on the idea of registering services with Barbican, even
 though (or maybe especially because) Barbican would not be using this data
 for anything.  I understand the problem that we’re trying to solve by
 associating different resources across projects, but I don’t feel like
 Barbican is the right place to do this.

Agreed also, this is simply not Barbican or Neutron's role. Be a REST
API for secrets and networking, not all dancing all singing nannies that
prevent any possibly dangerous behavior with said API's.

 It seems we’re leaning towards option #2, but I would argue that
 orchestration of services is outside the scope of Barbican’s role as a
 secret-store.  I think this is a problem that may need to be solved at a
 higher level.  Maybe an openstack-wide registry of dependend entities
 across services?
An optional openstack-wide registry of depended entities is called
Heat.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] KMIP support

[Clark, Robert Graham]

Thanks guys, you¹ve answered everything I needed to know!

I¹ll look to see what help I can provide to the KMIP efforts.

-Rob



On 04/06/2014 15:18, Becker, Bill bill.bec...@safenet-inc.com wrote:

Regarding:
 Also, is the ³OpenStack KMIP Client² ever going to be a thing?
 (https://wiki.openstack.org/wiki/KMIPclient)

We made some progress with some prototype code, but never completed the
effort. We subsequently marked the corresponding blueprint as obsolete:
https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encrypt
ion

The work that JHU/APL is doing to integrate KMIP into barbican supersedes
the original idea.

--Bill

-Original Message-
From: Nathan Reller [mailto:rellerrel...@yahoo.com]
Sent: Tuesday, June 03, 2014 8:50 AM
To: Openstack-Dev
Subject: Re: [openstack-dev] [Barbican] KMIP support

 I was wondering about the progress of KMIP support in Barbican?

As John pointed out, JHU/APL is working on adding KMIP support to
Barbican.
We submitted the first CR to add a Secret Store interface into Barbican.
The next step is to add a KMIP implementation of the Secret Store.

 Is this waiting on an open python KMIP support?

We are working in parallel to add KMIP support to Barbican and to release
an open source version of a Python KMIP library. We would like to have
both out by Juno.

 Also, is the ³OpenStack KMIP Client² ever going to be a thing?
 (https://wiki.openstack.org/wiki/KMIPclient)

That work was not proposed by us, so I can't comment on the status of
that.
Right now our path forward is to support Barbican by adding a KMIP Secret
Store.

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] KMIP support

[Clark, Robert Graham]

All,

I’m researching a bunch of HSM applications and I’m struggling to find much 
info. I was wondering about the progress of KMIP support in Barbican? Is this 
waiting on an open python KMIP support?

Also, is the “OpenStack KMIP Client” ever going to be a thing? 
(https://wiki.openstack.org/wiki/KMIPclient)

Cheers
-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

[Clark, Robert Graham]

Just chiming in with a side-note.

I always liked the idea of Postern for things like this though the crypto
geek in me always worries about making key retrieval too easy for
developers, bad things happen down that road.

The OSSG can help with overall secure design and would be happy to consult
if you¹d like. We have a separate list for security specific stuff but I
think a conversation on -dev would make more sense, just tag it [OSSG] :)

-Rob


On 28/05/2014 23:57, Nachi Ueno na...@ntti3.com wrote:

Hi Zang

Since, SSL-VPN for Juno bp is approved in neturon-spec,
I would like to restart this work.
Could you share your code if it is possible?
Also, Let's discuss how we can collaborate in here.

Best
Nachi


2014-05-01 14:40 GMT-07:00 Nachi Ueno na...@ntti3.com:
 Hi folks

 Clint
 Thanks, things get clear for me now :)





 2014-05-01 13:21 GMT-07:00 John Wood john.w...@rackspace.com:
 I was going to bring up Postern [1] as well, Clint. Unfortunately not
much work has been done on it though.

 [1] https://github.com/cloudkeep/postern

 Thanks,
 John



 
 From: Clint Byrum [cl...@fewbar.com]
 Sent: Thursday, May 01, 2014 2:22 PM
 To: openstack-dev
 Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

 Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700:
 Ah I got it now!
 so even if we get stolen HDD, we can keep password safe.

 However, I'm still not sure why this is more secure..
 anyway, the ID/PW to access barbican will be written in neutron.conf,
right?


 Yes. However, you can surround the secret in policies. You'll have an
 audit trail of when and where it was accessed, and you can even
restrict
 access, so that out of band you have to open up access with barbican.

 So while the server may have access, that access is now audited and
 limited by policy, instead of just being dependent on the security
 measures you can take to protect a file.

 Furthermore,  ID/PW for mysql will be written in conf file..
 so if we can't trust unix file system protection, there is no security
 in OpenStack.

 The ID/PW for mysql only grants you access to mysql for as long as that
 id/pw are enabled for access. However, the encryption keys for OpenVPN
 will grant any passive listener access for as long as they keep any
 sniffed traffic. They'll also grant an attacker the ability to MITM
 traffic between peers.

 So when an encryption key has been accessed, from where, etc, is quite
 a bit more crucial than knowing when a username/password combo have
 been accessed.

 Producing a trustworthy audit log for access to
/etc/neutron/neutron.conf
 is a lot harder than producing an audit log for a REST API.

 So it isn't so much that file system permissions aren't enough, it is
 that file system observability is expensive.

 Note that at some point there was a POC to have a FUSE driver backed by
 Barbican called 'Postern' I think. That would make these discussions a
 lot simpler. :)


 2014-05-01 10:31 GMT-07:00 Clint Byrum cl...@fewbar.com:
  I think you'd do something like this (Note that I don't know off
the top
  of my head the barbican CLI or openvpn cli switches... just
  pseudo-code):
 
  oconf=$(mktemp -d /tmp/openvpnconfig.XX)
  mount -o tmpfs $oconf size=1M
  barbican get my-secret-openvpn-conf  $oconf/foo.conf
  openvpn --config-dir $oconf foo --daemonize
  umount $oconf
  rmdir $oconf
 
  Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700:
  Hi Robert
 
  Thank you for your suggestion.
  so your suggestion is let OpenVPN process download key to memory
  directly from Babican?
 
  2014-05-01 9:42 GMT-07:00 Clark, Robert Graham
robert.cl...@hp.com:
   Excuse me interrupting but couldn't you treat the key as largely
   ephemeral, pull it down from Barbican, start the OpenVPN process
and
   then purge the key?  It would of course still be resident in the
memory
   of the OpenVPN process but should otherwise be protected against
   filesystem disk-residency issues.
  
  
   -Original Message-
   From: Nachi Ueno [mailto:na...@ntti3.com]
   Sent: 01 May 2014 17:36
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
  
   Hi Jarret
  
   IMO, Zang point is the issue saving plain private key in the
   filesystem for
   OpenVPN.
   Isn't this same even if we use Barbican?
  
  
  
  
  
   2014-05-01 2:56 GMT-07:00 Jarret Raim
jarret.r...@rackspace.com:
Zang mentioned that part of the issue is that the private key
has to
be stored in the OpenVPN config file. If the config files are
generated and can be stored, then storing the whole config
file in
Barbican protects the private key (and any other settings)
without
having to try to deliver the key to the OpenVPN endpoint in
some
   non-
   standard way.
   
   
Jarret
   
On 4/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote:
   
Jarret
   
   Thanks!
   Currently

Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

[Clark, Robert Graham]

Several OSSG members have expressed an interest in reviewing this
functionality too.

-Rob

On 28/05/2014 11:35, Samuel Bercovici samu...@radware.com wrote:

This very good news.
Please point to the code review in gerrit.

-Sam.


-Original Message-
From: Eichberger, German [mailto:german.eichber...@hp.com]
Sent: Saturday, May 24, 2014 12:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for
authentication

All,

Susanne and I had a demonstration of life code by HP's Barbican team
today for certificate storage. The code is submitted for review in the
Barbican project.

Barbican will be able to store all the certificate parts (cert, key, pwd)
in a secure container. We will follow up with more details next week --

So in short all we need to store in LBaaS is the container-id. The rest
will come from Barbican and the user will interact straight with Barbican
to upload/manage his certificates, keys, pwd...

This functionality/use case also is considered in the Marketplace /
Murano project -- making the need for a central certificate storage in
OpenStack a bit more pressing.

German

-Original Message-
From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Friday, May 23, 2014 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for
authentication

Right so are you advocating that the front end API never return a
private key back to the user once regardless if the key was generated on
the back end or sent in to the API from the user? We kind of are already
are implying that they can refer to the key via a private key id.


On May 23, 2014, at 9:11 AM, John Dennis jden...@redhat.com
 wrote:

 Using standard formats such as PEM and PKCS12 (most people don't use
 PKCS8 directly) is a good approach.

We had to deal with PKCS8 manually in our CLB1.0 offering at
rackspace. Too many customers complained.

 Be mindful that some cryptographic
 services do not provide *any* direct access to private keys (makes
 sense, right?). Private keys are shielded in some hardened container
 and the only way to refer to the private key is via some form of name
 association.

Were anticipating referring the keys via a barbican key id which will
be named later.


 Therefore your design should never depend on having access to a
 private key and

But we need access enough to transport the key to the back end
implementation though.

 should permit having the private key stored in some type of secure key
 storage.

   A secure repository for the private key is already a requirement that
we are attempting to meat with barbican.


 --
 John
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

[Clark, Robert Graham]

I’d like to attend all the Barbican stuff and I’m sure there’ll be some 
interesting Keystone things too.

I think it’s likely we’d do more parallel ‘OSSG’ stuff on the Keystone days 
though

I’m free on these dates.

From: Bryan Payne bdpa...@acm.orgmailto:bdpa...@acm.org
Date: Friday, 23 May 2014 02:14
To: Jarret Raim jarret.r...@rackspace.commailto:jarret.r...@rackspace.com
Cc: 
openstack-secur...@lists.openstack.orgmailto:openstack-secur...@lists.openstack.org
 
openstack-secur...@lists.openstack.orgmailto:openstack-secur...@lists.openstack.org,
 OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

I plan on attending.
-bryan


On Thu, May 22, 2014 at 10:48 AM, Jarret Raim 
jarret.r...@rackspace.commailto:jarret.r...@rackspace.com wrote:
All,

There was some interest at the Summit in semi-combining the mid-cycle meet
ups for Barbican, Keystone and the OSSG as there is some overlap in team
members and interest areas. The current dates being considered are:

Mon, July 7 - Barbican
Tue, July 8 - Barbican
Wed, July 9 - Barbican / Keystone
Thu, July 10 - Keystone
Fri, July 11 - Keystone

Assuming these dates work for for everyone, we'll fit some OSSG work in
during whatever days make the most sense. The current plan is to have the
meet up in San Antonio at the new Geekdom location, which is downtown.
This should make travel a bit easier for everyone as people won't need
cars are there are plenty of hotels and restaurants within walking / short
cab distance.

I wanted to try to get a quick head count from the Barbican and OSSG folks
(I think Dolph already has one for Keystone). I'd also like to know if you
are a Barbican person interested in going to the Keystone sessions or vice
versa.

Once we get a rough head count estimate, Dolph and I can work on getting
everything booked.





Thanks,

--
Jarret Raim
@jarretraim



___
Openstack-security mailing list
openstack-secur...@lists.openstack.orgmailto:openstack-secur...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [openstack-dev] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

[Clark, Robert Graham]

Yeah, I think they¹re rough for a few people, certainly doesn¹t make life
easier for those travelling big distances.

On 22/05/2014 21:19, Nathan Reller rellerrel...@yahoo.com wrote:

I am interested but the dates are a little rough because it is July 4th
weekend. Any chance of pushing it back a week? It might be easier to get
more
people to come that way.

-Nate

 All,

 There was some interest at the Summit in semi-combining the mid-cycle
meet
 ups for Barbican, Keystone and the OSSG as there is some overlap in team
 members and interest areas. The current dates being considered are:

 Mon, July 7 - Barbican
 Tue, July 8 - Barbican
 Wed, July 9 - Barbican / Keystone
 Thu, July 10 - Keystone
 Fri, July 11 - Keystone

 Assuming these dates work for for everyone, we'll fit some OSSG work in
 during whatever days make the most sense. The current plan is to have
the
 meet up in San Antonio at the new Geekdom location, which is downtown.
 This should make travel a bit easier for everyone as people won't need
 cars are there are plenty of hotels and restaurants within walking /
short
 cab distance.

 I wanted to try to get a quick head count from the Barbican and OSSG
folks
 (I think Dolph already has one for Keystone). I'd also like to know if
you
 are a Barbican person interested in going to the Keystone sessions or
vice
 versa.

 Once we get a rough head count estimate, Dolph and I can work on getting
 everything booked.

___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [Cinder][OSSG] Security note OSSN-0014 needs Cinder sign off

[Clark, Robert Graham]

Hi Cinder folks,

Malini from the security group has drafted an OpenStack Security Note for an 
issue regarding cinder driver permissions that was previously reported to the 
VMT.

Our process for publishing OSSNs requires sign off from two OSSN core and one 
core of the affected project(s) - we’d like someone from Cinder core could give 
it a quick sanity check before we publish it more widely.

https://review.openstack.org/#/c/92434/

Cheers
-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] A proposal for code reduction

[Clark, Robert Graham]

From: Abhijeet Jain [mailto:abhijeet.j...@nectechnologies.in] 
Sent: 21 May 2014 12:27
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] A proposal for code reduction

 

Hi Openstack-developers,

 

I am Abhijeet Jain. One of the contributor in OpenStack.

 

I was just working on optimizing the codes in Neutron , Keystone, Cinder
modules.

Then, I came across with a very common scenario that I can see at many
places.

at many places, I saw that the users have written the code in such form
:

 

assertEqual(user1['id'], user2['id']);

assertEqual(user1['name'], user2['name']);

assertEqual(user1['status'], user2['status']);

assertEqual(user1['xyz'], user2['xyz']);

 

 

To optimize such redundancy, I created a help function like below :

 

def _check(self, expected, actual, keys):

for key in keys:

assertEqual( expected[key], actual[key])

 

 

So, everywhere we just need to call this function like this :

_check(user1, user2, ['id', 'name', 'status', 'xyz'])

 

So, this way lots of code can be reduced.

but, currently i need to put that function in every test file , I want
to use. There is no global space.

 

My proposal is :

How about putting this function in some utils like place, which can be
accessed in every test function.

but for that, I need your approval.

Kindly, provide your valuable feedback on this.

 

 

 

Thanks,

Abhijeet Jain

 
 
Hi Abhijeet,
 
Excuse me if I've missed the point but it sounds like the oslo project
would be the place you'd want to put bits of shared code like this.
 
If you weren't already aware of it there's some great content here:
https://wiki.openstack.org/wiki/Oslo
 
Hope this helps
-Rob
 


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] Meeting time moving?

[Clark, Robert Graham]

Hi All,

At the summit I heard that the Barbican meeting time might be moving,
has anything been agreed? 

Cheers
-Rob



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Today's Meeting Cancelled

[Clark, Robert Graham]

Seems to be the way most people are going, I noticed Ironic announcing the
same today.

On 19/05/2014 19:46, Jarret Raim jarret.r...@rackspace.com wrote:

Barbicaneers,

Many of us are just getting back into the swing of things so we are going
to go ahead and cancel the meeting today. The main topic to be discussed
is our switch to using Gerrit for blueprints. The process is mostly
derived from Nova and is documented here:

https://wiki.openstack.org/wiki/Barbican/Blueprints


The proposed template for blueprints is here:

https://github.com/jarretraim/barbican-specs/blob/master/specs/template.rs
t



Please take a look at those and let me know if you see any problems.
Several of us will be on the #openstack-barbican channel if there are
issues to discuss.



Thanks!

--
Jarret Raim 
@jarretraim


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Using Nova client with SSH SOCKS proxy

[Clark, Robert Graham]

Is localhost listed in your /etc/hosts ?

Maybe try with HTTP_PROXY=http://127.0.0.1:13392 - just in case.

On 16/05/2014 11:41, Adrian Smith adr...@17od.com wrote:

To access my controller I need to go through a intermediary box.

I've created a local SOCKS proxy by ssh'ing to this intermediary with
the parameters -D 13392.

I then set the environment variable,
 export HTTP_PROXY=http://localhost:13392

But using nova list just gives an error,
$ nova list
ERROR: HTTPConnectionPool(host='localhost', port=13392): Max retries
exceeded with url: http://x.x.x.x:5000/v2.0/tokens (Caused by class
'httplib.BadStatusLine': '')

Should this work? Am I doing something wrong?

Adrian

___
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[Clark, Robert Graham]

The certificate management that LBaaS requires might be slightly
different to the normal flow of things in OpenStack services, after all
you are talking about externally provided certificates and private keys.

 

There's already a standard for a nice way to bundle those two elements
together, it's described in PKCS#12 and you've likely come across it in
the form of '.pfx' files. I'd suggest that perhaps it would make sense
for LBaaS to store pfx files in the LBaaS DB and store the key for the
pfx files in Barbican. You could probably store them together in
Barbican, using containers if you really wanted to
(https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-c
ontainer) 

 

-Rob

 

From: Carlos Garza [mailto:carlos.ga...@rackspace.com] 
Sent: 08 May 2014 04:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

 

On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.com
mailto:samu...@radware.com  wrote:





Hi John,

 

If the user already has an SSL certificate that was acquired outside of
the barbican Ordering system, how can he store it securely in Barbican
as a SSL Certificate?

The Container stored this information in a very generic way, I think
that there should be an API that formalizes a specific way in which SSL
certificates can be stored and read back as SSL Certificates and not as
loosely coupled container structure.

This such API should have RBAC that allows getting back only the public
part of an SSL certificate vs. allowing to get back all the details of
the SSL certificate.

 

Why the need for that complexity? The X509s are public by nature and
don't need to be stored in Barbican so there isn't really a private part
of the certificate. The actual private key itself is what needs to be
secured so I would advocate that the private key is what will be stored
in barbican. I also think we should also declare that the private key
need not be an RSA key as x509 supports other asymmetric encryption
types so storing as a generic blob in barbican is probably a good idea.

 





 

 

 

-Sam.

 

 

 

From: John Wood [mailto:john.wood@ http://RACKSPACE.COM RACKSPACE.COM]

Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions);
mailto:os.v...@gmail.com os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

Hello Samuel,

 

Just noting that the link below shows current-state Barbican. We are in
the process of designing SSL certificate support for Barbican via
blueprints such as this one:
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates

We intend to discuss this feature in Atlanta to enable coding in earnest
for Juno.

 

The Container resource is intended to capture/store the final
certificate details.

 

Thanks,

John

 

 


  _  


From: Samuel Bercovici [ mailto:samu...@radware.com
samu...@radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions);
mailto:os.v...@gmail.com os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

Hi Vijay,

 

I have looked at the Barbican APIs -
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Inte
rface
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Inter
face

I was no able to see a native API that will accept an SSL certificate
(private key, public key, CSR, etc.) and will store it.

We can either store the whole certificate as a single file as a secret
or use a container and store all the certificate parts as secrets.

 

I think that having LBaaS reference Certificates as IDs using some
service is the right way to go so this might be achived by either:

1.   Adding to Barbican and API to store / generate certificates

2.   Create a new module that might start by being hosted in
neutron or keystone that will allow to manage certificates and will use
Barbican behind the scenes to store them.

3.   Decide on a container structure to use in Babican but implement
the way to access and arrange it as a neutron library

 

Was any decision made on how to proceed?

 

Regards,

-Sam.

 

 

 

 

From: Vijay B [ mailto:os.v...@gmail.com mailto:os.v...@gmail.com] 
Sent: Wednesday, April 30, 2014 3:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation
for LBaaS and VPN

 

Hi,

 

It looks like there are areas of common effort in multiple efforts that
are proceeding in parallel to implement SSL for LBaaS as well as VPN SSL
in neutron.

 

Two relevant efforts are listed below:

 

 

 https://review.openstack.org/#/c/74031/

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[Clark, Robert Graham]

My understanding is that option 1. Is already moving at pace it might
just need a little finessing to ensure that it meets everyone's
requirements.

 

-Rob 

 

From: Samuel Bercovici [mailto:samu...@radware.com] 
Sent: 08 May 2014 11:20
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

Hi,

 

Please note as commented also by other XaaS services that managing SSL
certificates is not a sole LBaaS challenge.

This calls for either an OpenStack wide service or at least a Neutron
wide service to implement such use cases.

 

So it here are the options as far as I have seen so far.

1.  Barbican as a central service to store and retrieve SSL
certificates. I think the Certificates generation is currently a lower
priority requirement

2.  Using Heat as a centralized service 

3.  Implementing such service in Neutron

4.  LBaaS private implementation

 

BTW, on all the options above, Barbican can optionally be used to store
the certificates or the private part of the certificates.

 

I think that we either follow option 3 if SSL management is only a
Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition
project to an OpenStack wide solution (1 or 2).

Option 1 or 2 might be the ultimate goal.

 

Regards,

-Sam.

 

 

 

 

 

From: Clark, Robert Graham [mailto:robert.cl...@hp.com] 
Sent: Thursday, May 08, 2014 12:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

The certificate management that LBaaS requires might be slightly
different to the normal flow of things in OpenStack services, after all
you are talking about externally provided certificates and private keys.

 

There's already a standard for a nice way to bundle those two elements
together, it's described in PKCS#12 and you've likely come across it in
the form of '.pfx' files. I'd suggest that perhaps it would make sense
for LBaaS to store pfx files in the LBaaS DB and store the key for the
pfx files in Barbican. You could probably store them together in
Barbican, using containers if you really wanted to
(https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-c
ontainer) 

 

-Rob

 

From: Carlos Garza [mailto:carlos.ga...@rackspace.com] 
Sent: 08 May 2014 04:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

 

On May 7, 2014, at 10:53 AM, Samuel Bercovici samu...@radware.com
mailto:samu...@radware.com  wrote:

 

Hi John,

 

If the user already has an SSL certificate that was acquired outside of
the barbican Ordering system, how can he store it securely in Barbican
as a SSL Certificate?

The Container stored this information in a very generic way, I think
that there should be an API that formalizes a specific way in which SSL
certificates can be stored and read back as SSL Certificates and not as
loosely coupled container structure.

This such API should have RBAC that allows getting back only the public
part of an SSL certificate vs. allowing to get back all the details of
the SSL certificate.

 

Why the need for that complexity? The X509s are public by nature and
don't need to be stored in Barbican so there isn't really a private part
of the certificate. The actual private key itself is what needs to be
secured so I would advocate that the private key is what will be stored
in barbican. I also think we should also declare that the private key
need not be an RSA key as x509 supports other asymmetric encryption
types so storing as a generic blob in barbican is probably a good idea.

 

 

 

 

 

-Sam.

 

 

 

From: John Wood [mailto:john.wood@ http://RACKSPACE.COM RACKSPACE.COM]

Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions);
mailto:os.v...@gmail.com os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

Hello Samuel,

 

Just noting that the link below shows current-state Barbican. We are in
the process of designing SSL certificate support for Barbican via
blueprints such as this one:
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates

We intend to discuss this feature in Atlanta to enable coding in earnest
for Juno.

 

The Container resource is intended to capture/store the final
certificate details.

 

Thanks,

John

 

 


  _  


From: Samuel Bercovici [ mailto:samu...@radware.com
samu...@radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions);
mailto:os.v...@gmail.com os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron

Re: [openstack-dev] Security audit of OpenStack projects

[Clark, Robert Graham]

 -Original Message-
 From: John Dennis [mailto:jden...@redhat.com]
 Sent: 02 May 2014 14:23
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Security audit of OpenStack projects
 
 On 04/07/2014 12:06 PM, Nathan Kinder wrote:
  Hi,
 
  We don't currently collect high-level security related information
  about the projects for OpenStack releases.  Things like the crypto
  algorithms that are used or how we handle sensitive data aren't
  documented anywhere that I could see.  I did some thinking on how we
  can improve this.  I wrote up my thoughts in a blog post, which I'll
  link to instead of repeating everything here:
 
http://blog-nkinder.rhcloud.com/?p=51
 
  tl;dr - I'd like to have the development teams for each project keep
a
  wiki page updated that collects some basic security information.
  Here's an example I put together for Keystone for Icehouse:
 
https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
 
  There would need to be an initial effort to gather this information
  for each project, but it shouldn't be a large effort to keep it
  updated once we have that first pass completed.  We would then be
able
  to have a comprehensive overview of this security information for
each
  OpenStack release, which is really useful for those evaluating and
  deploying OpenStack.
 
  I see some really nice benefits in collecting this information for
  developers as well.  We will be able to identify areas of weakness,
  inconsistency, and duplication across the projects.  We would be
able
  to use this information to drive security related improvements in
  future OpenStack releases.  It likely would even make sense to have
  something like a cross-project security hackfest once we have taken
a
  pass through all of the integrated projects so we can have some
  coordination around security related functionality.
 
  For this to effort to succeed, it needs buy-in from each individual
  project.  I'd like to gauge the interest on this.  What do others
think?
   Any and all feedback is welcome!
 
 Catching up after having been away for a while.
 
 Excellent write-up Nathan and a good idea.
 
 The only suggestion I have at the moment is the information concerning
 how sensitive data is protected needs more explicit detail. For
example
 saying that keys and certs are protected by file system permissions is
not
 sufficient IMHO.
 
 Earlier this year when I went though the code that generates and
stores
 certs and keys I was surprised to find a number of mistakes in how the
 permissions were set. Yes, they were set, but no they weren't set
correctly.
 I'd like to see explicit listing of the user and group as well as the
modes and
 SELinux security contexts of directories, files (including unix
sockets). This
 will not only help other developers understand best practice but also
allow
 us to understand if we're following a consistent model across
projects.
 
 I realize some may say this falls into the domain of installers and
 packaging, but we should get it right ourselves and allow it to
serve as an
 example for installation scripts that may follow (many of which just
copy
 the values).

It's a great project, we really should be doing this more.

I think there's certainly scope to record 'installer' type information
too, in the
form of either recommendations or 'enhancements'. This information could
be aggregated in the OpenStack Hardening Guide too.

As Nathan said this really needs buy-in from individual teams in order
to pay 
off and the effort would need to be repeated for each release. I expect
that
future iterations would require a lot less effort than the first though.

Projects like this can be a bit of a time drain for core developers and
highly 
active code contributors but they're ideal for people starting off in a
project,
a nice way to have them look through the code, understand it and report
on it

I'd be very interested in any ideas on how to take this forward

-Rob



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

[Clark, Robert Graham]

Excuse me interrupting but couldn't you treat the key as largely
ephemeral, pull it down from Barbican, start the OpenVPN process and
then purge the key?  It would of course still be resident in the memory
of the OpenVPN process but should otherwise be protected against
filesystem disk-residency issues.


 -Original Message-
 From: Nachi Ueno [mailto:na...@ntti3.com]
 Sent: 01 May 2014 17:36
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
 
 Hi Jarret
 
 IMO, Zang point is the issue saving plain private key in the
filesystem for
 OpenVPN.
 Isn't this same even if we use Barbican?
 
 
 
 
 
 2014-05-01 2:56 GMT-07:00 Jarret Raim jarret.r...@rackspace.com:
  Zang mentioned that part of the issue is that the private key has to
  be stored in the OpenVPN config file. If the config files are
  generated and can be stored, then storing the whole config file in
  Barbican protects the private key (and any other settings) without
  having to try to deliver the key to the OpenVPN endpoint in some
non-
 standard way.
 
 
  Jarret
 
  On 4/30/14, 6:08 PM, Nachi Ueno na...@ntti3.com wrote:
 
  Jarret
 
 Thanks!
 Currently, the config will be generated on demand by the agent.
 What's merit storing entire config in the Barbican?
 
  Kyle
 Thanks!
 
 2014-04-30 7:05 GMT-07:00 Kyle Mestery
 mest...@noironetworks.com:
  On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno na...@ntti3.com
 wrote:
  Hi Clint
 
  Thank you for your suggestion. Your point get taken :)
 
  Kyle
  This is also a same discussion for LBaaS Can we discuss this in
  advanced service meeting?
 
  Yes! I think we should definitely discuss this in the advanced
  services meeting today. I've added it to the agenda [1].
 
  Thanks,
  Kyle
 
  [1]
 https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f
 or_
 next
 _meeting
 
  Zang
  Could you join the discussion?
 
 
 
  2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com:
  Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700:
  Hi Kyle
 
  2014-04-29 10:52 GMT-07:00 Kyle Mestery
 mest...@noironetworks.com:
   On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno
 na...@ntti3.com
 wrote:
   Hi Zang
  
   Thank you for your contribution on this!
   The private key management is what I want to discuss in the
 summit.
  
   Has the idea of using Barbican been discussed before? There
are
 many
   reasons why using Barbican for this may be better than
   developing
 key
   management ourselves.
 
  No, however I'm +1 for using Barbican. Let's discuss this in
  certificate management topic in advanced service session.
 
 
  Just a suggestion: Don't defer that until the summit. Sounds
like
 you've  already got some consensus, so you don't need the summit
 just to rubber  stamp it. I suggest discussing as much as you can
 right now on the mailing  list, and using the time at the summit
to
 resolve any complicated issues  including any a or b things
that
 need crowd-sourced idea making. You  can also use the summit time
 to communicate your requirements to the  Barbican developers.
 
  Point is: just because you'll have face time, doesn't mean you
  should use it for what can be done via the mailing list.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [Openstack-security] API Security

[Clark, Robert Graham]

This is why any production API servers should all be running TLS/SSL – to 
protect the confidentiality of messages in flight.

 

There have been efforts to remove sensitive information from logs, I’m a little 
surprised that passwords are logged in Neutron.

 

From: Hao Wang [mailto:hao.1.w...@gmail.com] 
Sent: 29 April 2014 14:06
To: openstack-secur...@lists.openstack.org
Cc: openstack; Aaron Knister
Subject: Re: [Openstack-security] [Openstack] API Security

 

Adding security group...

 

On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang hao.1.w...@gmail.com 
mailto:hao.1.w...@gmail.com  wrote:

It is the client. I got this message with DEBUG enabled:

curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H Content-Type: 
application/json -H Accept: application/json -H User-Agent: 
python-novaclient -d '{auth: {tenantName: admin, passwordCredentials: 
{username: admin, password: admin}}}'

 

It can be seen that username and password are right in the message.

 

Hao

 

On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister aaron.knis...@gmail.com 
mailto:aaron.knis...@gmail.com  wrote:

Was it the client or the server that exposed the credentials?

Sent from my iPhone


On Apr 26, 2014, at 2:28 PM, Hao Wang hao.1.w...@gmail.com 
mailto:hao.1.w...@gmail.com  wrote:

Hi,

 

I am troubleshooting a neutron case. It was just found that if DEBUG was 
enabled, neutron would print out JSON data with username and password. I am 
wondering what kind of protocol is used in production environment to prevent 
this security risk from happening.

 

Thanks,

Hao

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org 
mailto:openstack@lists.openstack.org 
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Openstack-security] API Security

[Clark, Robert Graham]

I'd say the top three terminators in use today are probably Stunnel,
Stud and Pound - all rely on OpenSSL. I'm sure there's a plethora of
alternatives but I'd imagine most are OpenSSL based, the most likely
alternative being NSS which is a big library to use for something like a
terminator.

 -Original Message-
 From: Rob Crittenden [mailto:rcrit...@redhat.com]
 Sent: 29 April 2014 15:39
 To: Hao Wang; Clark, Robert Graham
 Cc: openstack-secur...@lists.openstack.org; openstack; Aaron Knister
 Subject: Re: [Openstack-security] [Openstack] API Security
 
 Hao Wang wrote:
  Thanks. It makes sense. The other questions are, would Heartbleed be
a
  potential risk? Which solution is being used in OpenStack SSL?
 
 Native SSL services (eventlet) are based on OpenSSL, as is Apache
 (horizon) so yes, the risk is there if you haven't updated your
OpenSSL
 libraries.
 
 The general consensus however is to use SSL terminators rather than
 enabling SSL in the endpoints directly. You'd need to investigate the
SSL
 library in the terminator you choose, though it would likely be
OpenSSL.
 
 Check this out as well, https://blog-nkinder.rhcloud.com/?p=7
 
 rob
 
 
 
  On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham
  robert.cl...@hp.com mailto:robert.cl...@hp.com wrote:
 
  This is why any production API servers should all be running
TLS/SSL
  - to protect the confidentiality of messages in flight.
 
  __ __
 
  There have been efforts to remove sensitive information from
logs,
  I'm a little surprised that passwords are logged in Neutron.
 
  __ __
 
  *From:*Hao Wang [mailto:hao.1.w...@gmail.com
  mailto:hao.1.w...@gmail.com]
  *Sent:* 29 April 2014 14:06
  *To:* openstack-secur...@lists.openstack.org
  mailto:openstack-secur...@lists.openstack.org
  *Cc:* openstack; Aaron Knister
  *Subject:* Re: [Openstack-security] [Openstack] API Security
 
  __ __
 
  Adding security group...
 
  __ __
 
  On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang hao.1.w...@gmail.com
  mailto:hao.1.w...@gmail.com wrote:
 
  It is the client. I got this message with DEBUG enabled:
 
  curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
  Content-Type: application/json -H Accept:
application/json
  -H User-Agent: python-novaclient -d '{auth:
{tenantName:
  admin, passwordCredentials: {username: admin,
  password: admin}}}'
 
  __ __
 
  It can be seen that username and password are right in the
  message.
 
  __ __
 
  Hao
 
  __ __
 
  On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister
  aaron.knis...@gmail.com mailto:aaron.knis...@gmail.com
  wrote:
 
  Was it the client or the server that exposed the
credentials?
 
  Sent from my iPhone
 
 
  On Apr 26, 2014, at 2:28 PM, Hao Wang
hao.1.w...@gmail.com
  mailto:hao.1.w...@gmail.com wrote:
 
  Hi,
 
  __ __
 
  I am troubleshooting a neutron case. It was just
found
  that if DEBUG was enabled, neutron would print out
JSON
  data with username and password. I am wondering what
  kind of protocol is used in production environment
to
  prevent this security risk from happening.
 
  __ __
 
  Thanks,
 
  Hao
 
  ___
  Mailing list:
 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
  Post to : openstack@lists.openstack.org
  mailto:openstack@lists.openstack.org
  Unsubscribe :
 
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 
  __ __
 
  __ __
 
 
 
 
  ___
  Openstack-security mailing list
  openstack-secur...@lists.openstack.org
 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
 



smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Openstack-security] API Security

[Clark, Robert Graham]

You can terminate SSL anywhere, it doesn’t have to be at the boundary 
necessarily. Many larger deployments will utilize hardware terminators at the 
network edge and then internally use software based terminators (like Stunnel).

 

There’s a growing effort to use SSL everywhere, I can second Rob Crittenden’s 
comments – check out Nathan Kinders blog entry on the topic 
https://blog-nkinder.rhcloud.com/?p=7

 

From: Hao Wang [mailto:hao.1.w...@gmail.com] 
Sent: 29 April 2014 16:04
To: Rob Crittenden
Cc: Clark, Robert Graham; openstack-secur...@lists.openstack.org; openstack; 
Aaron Knister
Subject: Re: [Openstack-security] [Openstack] API Security

 

SSL terminator will terminates at the network boundary. I am thinking if the 
crackers can figure out a way to sneak into the internal network and capture 
all the sensitive information still. Is this a concern for a private cloud?

 

On Tue, Apr 29, 2014 at 10:39 AM, Rob Crittenden rcrit...@redhat.com 
mailto:rcrit...@redhat.com  wrote:

Hao Wang wrote:

Thanks. It makes sense. The other questions are, would Heartbleed be a
potential risk? Which solution is being used in OpenStack SSL?

 

Native SSL services (eventlet) are based on OpenSSL, as is Apache (horizon) so 
yes, the risk is there if you haven't updated your OpenSSL libraries.

The general consensus however is to use SSL terminators rather than enabling 
SSL in the endpoints directly. You'd need to investigate the SSL library in the 
terminator you choose, though it would likely be OpenSSL.

Check this out as well, https://blog-nkinder.rhcloud.com/?p=7

rob



On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham

robert.cl...@hp.com mailto:robert.cl...@hp.com  mailto:robert.cl...@hp.com 
mailto:robert.cl...@hp.com  wrote:

This is why any production API servers should all be running TLS/SSL

– to protect the confidentiality of messages in flight.

__ __



There have been efforts to remove sensitive information from logs,

I’m a little surprised that passwords are logged in Neutron.

__ __

*From:*Hao Wang [mailto:hao.1.w...@gmail.com mailto:hao.1.w...@gmail.com 
mailto:hao.1.w...@gmail.com mailto:hao.1.w...@gmail.com ]
*Sent:* 29 April 2014 14:06
*To:* openstack-secur...@lists.openstack.org 
mailto:openstack-secur...@lists.openstack.org 
mailto:openstack-secur...@lists.openstack.org 
mailto:openstack-secur...@lists.openstack.org 
*Cc:* openstack; Aaron Knister
*Subject:* Re: [Openstack-security] [Openstack] API Security

__ __

Adding security group...

__ __



On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang hao.1.w...@gmail.com 
mailto:hao.1.w...@gmail.com 

mailto:hao.1.w...@gmail.com mailto:hao.1.w...@gmail.com  wrote:

It is the client. I got this message with DEBUG enabled:



curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
Content-Type: application/json -H Accept: application/json
-H User-Agent: python-novaclient -d '{auth: {tenantName:
admin, passwordCredentials: {username: admin,

password: admin}}}'

__ __



It can be seen that username and password are right in the

message.

__ __

Hao

__ __



On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister

aaron.knis...@gmail.com mailto:aaron.knis...@gmail.com  
mailto:aaron.knis...@gmail.com mailto:aaron.knis...@gmail.com 
wrote:



Was it the client or the server that exposed the credentials?

Sent from my iPhone




On Apr 26, 2014, at 2:28 PM, Hao Wang hao.1.w...@gmail.com 
mailto:hao.1.w...@gmail.com 

mailto:hao.1.w...@gmail.com mailto:hao.1.w...@gmail.com  
wrote:

Hi,

__ __



I am troubleshooting a neutron case. It was just found
that if DEBUG was enabled, neutron would print out JSON
data with username and password. I am wondering what
kind of protocol is used in production environment to

prevent this security risk from happening.

__ __

Thanks,

Hao



___
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org 
mailto:openstack@lists.openstack.org 

mailto:openstack@lists.openstack.org 
mailto:openstack@lists.openstack.org 
Unsubscribe :

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

__ __

__ __




___
Openstack-security mailing list
openstack-secur...@lists.openstack.org 
mailto:openstack-secur...@lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo

[Openstack] [Barbican] Key Recovery / Availability

[Clark, Robert Graham]

Has there been much discussion on how to ensure that keys are
recoverable in the event that Barbican has some sort of horrific
failure? 

I suppose a HA frontend, Redundant Keystore Databases and HA paired HSMs
would be the most obvious non-code-writing path but this feels pretty
clunky, I was wondering if it had been discussed yet? Possibly it should
be something for a design session?

-Rob



smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Barbican] Key Recovery / Availability

[Clark, Robert Graham]

 -Original Message-
 From: Clint Byrum [mailto:cl...@fewbar.com]
 Sent: 19 March 2014 18:22
 To: openstack
 Subject: Re: [Openstack] [Barbican] Key Recovery / Availability
 
 Excerpts from Clark, Robert Graham's message of 2014-03-19 07:41:35 -
 0700:
  Has there been much discussion on how to ensure that keys are
  recoverable in the event that Barbican has some sort of horrific
  failure?
 
  I suppose a HA frontend, Redundant Keystore Databases and HA paired
  HSMs would be the most obvious non-code-writing path but this feels
  pretty clunky, I was wondering if it had been discussed yet?
Possibly
  it should be something for a design session?
 
 
 Sorry, what is clunky about backing up your data?
 
 ___

There's nothing clunky about backups, I was just wondering what
approaches people were considering for data resiliency in Barbican,
beyond the obvious scenario I described.


smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Barbican] Key Recovery / Availability

[Clark, Robert Graham]

As the services I described were the first things that came into my mind with 
regards to high availability in Barbican I assumed that there was probably a 
better strategy.

If the strategy is as you've described then that's great -  even I can 
understand that!

-Rob
 
 Our plan for deployment is exactly as Clark described:
 
 
 * Several API nodes behind a load balancer
 * PostgreSQL master/slave replication
 * HSMs in HA paired mode
 * Several Worker nodes
 
 I’m also curios as to why this would be considered “clunky”?
 
 -Doug
 
 On 3/19/14, 1:21 PM, Clint Byrum cl...@fewbar.com wrote:
 
 Excerpts from Clark, Robert Graham's message of 2014-03-19 07:41:35 -
 0700:
  Has there been much discussion on how to ensure that keys are
  recoverable in the event that Barbican has some sort of horrific
  failure?
 
  I suppose a HA frontend, Redundant Keystore Databases and HA paired
  HSMs would be the most obvious non-code-writing path but this feels
  pretty clunky, I was wondering if it had been discussed yet? Possibly
  it should be something for a design session?
 
 
 Sorry, what is clunky about backing up your data?
 
 ___
 Mailing list:
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openstack@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Barbican] HTTPS Connection Question

[Clark, Robert Graham]

Very often you’ll deploy them on the same server, so no plaintext goes over the 
wire.

 

-Rob

 

From: Miller, Mark M (EB SW Cloud - RD - Corvallis) 
Sent: 05 March 2014 20:31
To: Douglas Mendizabal; Tiwari, Arvind; Ferreira, Rafael; Remo Mattei; Wyllys 
Ingersoll; openstack@lists.openstack.org
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question

 

Hello,

 

I now have a web server question. I just configured NGINX to server as an HTTPS 
front end. If I am not mistaken, NGINX receives the HTTPS requests and then 
makes an HTTP request to the uWSGI server  which parses the request and calls 
Barbican directly passing in the request parameters. Is this correct?

 

If so, how do I remove uWSGI as a middleman? Insecure HTTP requests are not 
permitted in my environment.

 

Regards,

 

Mark Miller

 

 

From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] 
Sent: Wednesday, March 05, 2014 9:07 AM
To: Tiwari, Arvind; Miller, Mark M (EB SW Cloud - RD - Corvallis); Ferreira, 
Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.org 
mailto:openstack@lists.openstack.org 
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question

 

Arvind,

 

I think you are confused about HTTPS support.  

 

 Barbican does not support SSL , I have added BP for the same.

This is a false statement.  Barbican does not need to support SSL.  It’s up to 
the container (aka the Web Server) being used to provide SSL for the 
application, just as you’ve shown in the wiki entry to set up Nginx with SSL.  
There is nothing that we can do to “add SSL to Barbican”, so I’m not sure what 
your blueprint is trying to accomplish.

 

Thanks,

-Doug

 

From: Tiwari, Arvind arvind.tiw...@hp.com mailto:arvind.tiw...@hp.com 
Date: Tuesday, March 4, 2014 at 7:08 PM
To: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com 
mailto:mark.m.mil...@hp.com , Douglas Mendizabal 
douglas.mendiza...@rackspace.com mailto:douglas.mendiza...@rackspace.com , 
Ferreira, Rafael r...@io.com mailto:r...@io.com , Remo Mattei 
r...@italy1.com mailto:r...@italy1.com , Wyllys Ingersoll 
wyllys.ingers...@evault.com mailto:wyllys.ingers...@evault.com , 
openstack@lists.openstack.org mailto:openstack@lists.openstack.org  
openstack@lists.openstack.org mailto:openstack@lists.openstack.org 
Subject: RE: [Openstack] [Barbican] HTTPS Connection Question

 

Hi Mark,

 

Barbican does not support SSL , I have added BP for the same.

https://blueprints.launchpad.net/barbican/+spec/transport-layer-security-is-needed-in-barbican

 

I have added this page which uses NginX (I like better than APache) to provide 
SSL support 

https://github.com/cloudkeep/barbican/wiki/Deploy-OpenStack-Barbican-with-Nginx-web-server

 

Hope this will help.

 

Thanks,

Arvind

 

 

From: Miller, Mark M (EB SW Cloud - RD - Corvallis) 
Sent: Tuesday, March 04, 2014 4:34 PM
To: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; 
openstack@lists.openstack.org mailto:openstack@lists.openstack.org 
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question

 

Hello Doug,

 

Thank you for the information. I will keep you informed if we decide to use 
Apache2 as a front end.

 

Regards,

 

Mark

 

From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] 
Sent: Tuesday, March 04, 2014 2:47 PM
To: Miller, Mark M (EB SW Cloud - RD - Corvallis); Ferreira, Rafael; Remo 
Mattei; Wyllys Ingersoll; openstack@lists.openstack.org 
mailto:openstack@lists.openstack.org 
Subject: Re: [Openstack] [Barbican] HTTPS Connection Question

 

Hi Mark,

 

I hope I can answer your questions:

 

1. HTTP support should be provided by the web server used to host barbican, not 
by barbican itself.  The files where you noticed the “protocol = http” settings 
are uwsgi configuration files the Barbican team uses to run Barbican using 
uwsgi during development.  The settings are just default development settings, 
and should be tuned to your particular situation.  You can find more 
information about uwsgi config options on their official documentation. [1]  In 
particular, you may be interested in enabling HTTPS support documentation. [2]

 

2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there 
are no dependencies on uwsgi built into barbican.  This means that, in theory, 
you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + 
gunicorn, or any other web server capable of hosting a WSGI app.  That said, we 
have not actually built environments with alternative web servers, so we don’t 
currently have any documentation on how to set that up.   If you decide to 
deploy Barbican using Apache, we’d love to hear about your experience and help 
out in any way we can (join us at #openstack-barbican on Freenode).  I would 
encourage you to contribute to our documentation wiki if you are successful.

 

Regards,

-Doug Mendizabal

 

[1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html

[2] 

Re: [Openstack] Plaintext password in getCredential token

[Clark, Robert Graham]

On Wed Feb  5 08:34:34 2014, Rob Crittenden wrote:
 Emanuel Marzini wrote:
 Hi,
 I have a software that uses Openstack. When it do an action for the
 first time, it need to get a token from Openstack. How it's possible
 make a POST request like:

 '{auth:{passwordCredentials:{username: joeuser, password:
 secrete}}}' -H Content-type: application/json
 http://localhost:35357/v2.0/tokens

 without pass the password in plaintext???

 It's possible use PKI, ssl and so on?

 The documentation on this is scant but you can start with something like
 http://docs.openstack.org/developer/keystone/configuration.html

 You'll need to create new endpoints for the SSL provider and set
 OS_SERVICE_ENDPOINT to the secure version.

 If you want to disable/remove the unsecure ports things get rather
 interesting as you'll need to configure all the other services to use
 this as well. I don't know how well or if that actually works everywhere.

 rob


You might find some of the guidance from the OpenStack Security Guide 
useful too: 
http://docs.openstack.org/security-guide/content/ch024_authentication.html



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [swift] Is anyone using cloudfuse successfully?

[Clark, Robert Graham]

On Thu Jan 23 07:41:09 2014, Joe Topjian wrote:
 A group I'm working with recently finished some basic cloudfuse
 testing and in the end, we weren't 100% comfortable with using it in
 production. The core reason for this is cloudfuse writing files to
 /tmp before they get moved to Swift. We played with a few variations
 of /tmp including using a ramdisk for /tmp, but we were unable to find
 a way where the IO of /tmp or the limited memory of a ramdisk /tmp
 would not be a bottleneck for the traffic we were aiming for.

   Also have you looked the gluster-swift project to see what they
 are doing?

 I have not.  I wasn't aware that they included a client or fusedriver
 like this.  I'll look into it.


 For reference, gluster-swift can be read about here:

 https://github.com/gluster/gluster-swift/blob/havana/doc/markdown/quick_start_guide.md

 It allows Swift to use GlusterFS as a backing store. Swift is still
 accessed via HTTP, which is the opposite cloudfuse's goal.

Could you share a little bit more about your use case or testing 
please? I'm currently re-implementing cloudfuse and I'm surprised by 
your comments around the use of temporary files are you working with a 
local (not over the internet) object store?

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [ironic] Disk Eraser

[Clark, Robert Graham]

On 17/01/2014 08:19, Robert Collins wrote:
 On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote:
 Hi fellow OpenStackers



 Does anyone have any recommendations on open source tools for disk
 erasure/data destruction software. I have so far looked at DBAN and disk
 scrubber and was wondering if ironic team have some better recommendations?

 So for Ironic this is a moderately low priority thing right now - and
 certainly I think it should be optional (what the default is is a
 different discussion).

 It's low priority because there are -so- many other concerns about
 sharing bare metal machines between tenants that don't have
 comprehensive mutual trust, that it's really not viable today (even on
 relatively recent platforms IMNSHO).

 -Rob



For all but the most paranoid of applications a single pass overwrite is 
enough to ensure that all data is securely removed from a magnetic disk.

There is some truth to the claim that data can still be read after a 
re-write, the technique is known as magnetic force microscopy 
(https://www.usenix.org/legacy/publications/library/proceedings/sec96/full_papers/gutmann/index.html),
 
it's an incredibly expensive method of data recovery, used only by a few 
organisations most of which I assume are intelligence agencies.

A single pass overwrite is fine for wiping the contents of a disk beyond 
all reasonable means of recovery. If you're trying to protect your data 
from recovery by intelligence agencies with access to the hardware, 
there are probably a lot of more important things you need to do to 
secure your data before you try to work out how many deban-re-writes you 
want.

SSD's are more complicated because they have wear-leveling controllers 
that spread data out in ways that mean you can't necessarily guarantee 
that every block will get written during an overwrite.

If you'd like a more detailed answer I'm sure the folks in the OSSG 
would be happy to help: openstack-secur...@lists.openstack.org

Cheers
-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Incubation Request for Barbican

[Clark, Robert Graham]

From: Bryan D. Payne [mailto:bdpa...@acm.org] 
Sent: 12 December 2013 16:12
To: OpenStack Development Mailing List (not for usage questions)
Cc: openstack...@lists.openstack.org; cloudkeep@googlegroups. com;
barbi...@lists.rackspace.com
Subject: Re: [openstack-dev] Incubation Request for Barbican

 

$ git shortlog -s -e | sort -n -r
   172 John Wood john.w...@rackspace.com
   150 jfwood john.w...@rackspace.com
65 Douglas Mendizabal douglas.mendiza...@rackspace.com
39 Jarret Raim jarret.r...@rackspace.com
17 Malini K. Bhandaru malini.k.bhand...@intel.com
10 Paul Kehrer paul.l.keh...@gmail.com
10 Jenkins jenk...@review.openstack.org
 8 jqxin2006 jqxin2...@gmail.com
 7 Arash Ghoreyshi arashghorey...@gmail.com
 5 Chad Lung chad.l...@gmail.com
 3 Dolph Mathews dolph.math...@gmail.com
 2 John Vrbanac john.vrba...@rackspace.com
 1 Steven Gonzales stevendgonza...@gmail.com
 1 Russell Bryant rbry...@redhat.com
 1 Bryan D. Payne bdpa...@acm.org

It appears to be an effort done by a group, and not an individual.
Most
commits by far are from Rackspace, but there is at least one
non-trivial
contributor (Malini) from another company (Intel), so I think this is
OK.

There has been some interest from some quarters (RedHat, HP and others)
in
additional support. I hope that the incubation process will help
accelerate external contributions.

 

For what it's worth, I just wanted to express my intent to get more
involved in Barbican in the near future.  I plan to be helping out with
both reviews and coding on a variety of pieces.  So that will help (a
little) with the diversification situation.  I would also mention that
there has been great interest in Barbican among the OSSG crowd and it
wouldn't surprise me to see more people from that group getting involved
in the future.

 

Cheers,

-bryan

 

Just adding a +1 here from HP.

 

We're very excited about some of the capabilities that Barbican will
bring and will be engaging with the development of the project.

 

Cheers,

-Rob



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] [OSSG][OSSN] Restarting memcached loses revoked token list

[Clark, Robert Graham]

Restarting memcached loses revoked token list
-

### Summary ###
When a cloud is deployed using Memcache as a backend for Keystone tokens
there is a security concern that restarting Memcached will lose the list
of revoked tokens, potentially allowing bad tokens / users to access the
system after they had been revoked.

### Affected Services / Software ###
Keystone, Memcache

### Discussion ###
There might be ways to mitigate in the future, such as running memcached
on multiple machines to ensure redundancy should the Keystone server
fail. In a clustered environment, it will only be an issue if all of the
memcached machines shutdown.

Memcachedb might also be a potential way to mitigate.
http://memcachedb.org/

NOTE: Some deployments may intentionally flush Memcached in response to
https://bugs.launchpad.net/ossn/+bug/1179955 - please exercise caution
when considering how to approach this problem.

### Recommended Actions ###
This is a fundamental problem with using in-memory ephemeral storage for
security information. If your deployment has strong security
requirements or a reliance on up-to-date revoked token information we
suggest you consider using an on-disk DB such as MySQL / PostgreSQL or
perhaps look into Memcachedb.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1182920
Blueprint :
https://blueprints.launchpad.net/keystone/+spec/revocation-backend
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg





smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSG][OSSN] HTTP Strict Transport Security not enabled on Horizon Dashboard

[Clark, Robert Graham]

HTTP Strict Transport Security not enabled on Horizon Dashboard


### Summary ###
 Cloud operators using Horizon for production or internet facing
operations should strongly consider configuring HSTS for their
deployment

### Affected Services / Software ###
Horizon, SSL, TLS, Apache, Nginx

### Discussion ###
HTTP Strict Transport Security (HSTS) enforces that all communications
with a server go over SSL. This mitigates the threat from attacks such
as SSL-Strip which replaces links on the wire, stripping away https
prefixes and potentially allowing an attacker to view confidential
information on the wire.

HSTS can be enabled in Apache and Nginx, the two primary ways of serving
Horizon at scale.

### Recommended Actions ###
Apache Configuration:
-
Add this to the relevant vhost:
Header add Strict-Transport-Security max-age=15768000

We suggest also using mod_rewrite to ensure all visitors to Horizon land
on a secure page
Add this into your main configuration file
IfModule mod_rewrite.c
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
/IfModule

Nginx Configuration:

add_header Strict-Transport-Security max-age=15768000;

As always, test these configuration settings before deploying them to
production in order to catch any bugs etc.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1191050
Documentation Bug :
https://bugs.launchpad.net/openstack-manuals/+bug/1210409
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack