juju openstack environments have no security

Bug #1226996 reported by Kapil Thangavelu
262
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Go OpenStack Exchange
Invalid
High
Unassigned
juju-core
Fix Released
Critical
John A Meinel
1.14
Fix Released
Critical
John A Meinel

Bug Description

Every environment on the openstack provider has no network security. The security rule for internal ingress was fubar'd to allow access to the entire world. It means expose/unexpose is meaningless, and anything listening on a port is available to the world by default.

Related branches

Revision history for this message
John A Meinel (jameinel) wrote :

Essentially, we don't set a Cidr, so openstack is picking 0.0.0.0/0 by default, and we failed to set the group_id (and possibly parent_group_id). To be fair, it isn't actually documented in their API docs (that I can find)
http://docs.openstack.org/api/openstack-network/2.0/content/POST_createSecGroupRule__security-group-rules_.html
http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroup_api_abstractions.html

but we are passing parent_group_id and group_id in the Python implementation.

Changed in juju-core:
status: Confirmed → Triaged
Revision history for this message
John A Meinel (jameinel) wrote :

While not strictly a regression (we've built the security group this way from the beginning) it is worth back porting to the 1.14 series.

Revision history for this message
John A Meinel (jameinel) wrote :

I *think* we'll need to update Goose to handle the new fields.

Changed in goose:
importance: Undecided → Critical
status: New → In Progress
Revision history for this message
John A Meinel (jameinel) wrote :

It looks like Goose already supported the field we wanted to use, we just needed to add it.

Changed in goose:
importance: Critical → High
status: In Progress → Invalid
Revision history for this message
Kapil Thangavelu (hazmat) wrote :

hi john, thanks for fixing. re to be fair comment.. to be fair.. it was a lack of testing and attention to detail that caused it not a lack of docs. ie for something that's fundamental to the security of an environment, we need to hold ourselves to a higher standard than it ran without error.. ie verify it works as expected.

Mark Ramm (mark-ramm)
Changed in juju-core:
assignee: nobody → John A Meinel (jameinel)
Curtis Hovey (sinzui)
information type: Private Security → Public Security
Curtis Hovey (sinzui)
Changed in juju-core:
status: Triaged → Fix Committed
milestone: none → 1.15.0
John A Meinel (jameinel)
Changed in juju-core:
status: Fix Committed → Fix Released
Revision history for this message
Michael Nelson (michael.nelson) wrote :

It may be worth updating setUpGlobalGroup so that it *checks* the existing global group, rather than just ensureGroup. I hadn't used the openstack provider for a long time (it seems since before this was fixed), so when I just bootstrapped and deployed a service, I found all ports were already exposed.

Turns out it was because the juju-openstack secgroup already existed. Destroying the environment, manually deleting the secgroups and retrying gave the correct secgroup with the groupid set as per the fix.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.