![/!\](/moin_static192/OpenStack/img/alert.png "/!\"){kind=small}
Work in progress!
Launchpad Entry: bexar-iptables-security-groups or foo
Created: 2010-12-03
Contributors: SorenHansen
Summary
Add a security groups implementation based on iptables (rather than libvirt's nwfilter).
Release Note
We added a new backend for security groups that uses iptables directly instead of relying on libvirt's nwfilter. Among other things, this means that it now actually works.
Rationale
NWFilter doesn't really work at the moment (due to kernel limitations), and the known workarounds cannot be applied to NWFilter, so we have to look elsewhere for a proper solution adding security groups.
Design
We add a couple of extra rpc methods:
- refresh_security_group_members(group_id): Emitted whenever a member is added or removed from a security group.
- refresh_security_group_rules(group_id): Emitted when a rule is added to or removed from a security group.
In the EC2 API, the following API calls are affected:
RunInstances starts a new instance, adding it to a set of security groups. refresh_security_group_members is called for each security group. Each compute node hosting an instance that has a security group rule referencing the affected security group should receive the call.
AuthorizeSecurityGroupIngressRule adds a rule to and RevokeSecurityGroupIngressRule removes a rule form a security group. refresh_security_group_rules is called. Each compute node hosting an instance that is a member of the affected security group should receive the call.
We could potentially have offloaded some of this logic to rabbit by having a topic per security group and just broadcast "refresh_members" and "refresh_rules" on those, but given that we'll potentially have a million of these security groups, that doesn't seem very pleasant.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.