The document discusses the proposal to transition security groups from Nova to Quantum within the OpenStack framework, highlighting the differences and improvements in security group features and APIs. Key points include the current model's limitations, proposed enhancements for firewall capabilities, and the introduction of per-port security group associations. The session aims to facilitate a discussion on access control lists, provider firewalling, and user modifications to security groups.

1. Quantum Security Groups
Session
Dave Lapsley
@davlaps
http://slidesha.re/HQvDTk
http://etherpad.openstack.org/quantum-folsom

2. Session Goals
• Introduction to Nova Security Groups
• Proposal:
– Move Security Groups from Nova to Quantum
• Discussion:
– Provider Firewalling
– Access Control Lists
– Other

3. Proposal: move Security Groups
from Nova to Quantum
Naturally fit within network API
Allow plugins to implement them
in a compatible way

4. Features and Use Cases

5. Nova Security Groups
• Collection of network access rules that
specify what traffic is allowed to ingress a VM
• Associated with a VM at startup
– If Security Group not specified, VM belongs to
default Security Group which allows traffic from all
other members of the group
• A VM can be associated with many Security
Groups
• Security Rule specifies:
– Source of traffic (IP subnet in CIDR notation, or
another security group)
– Protocol (TCP, UDP, ICMP)
– Destination port on VM

6. Security Group Command Line
EC2 Openstack Nova
euca-add-group secgroup-add-group-rule
euca-authorize secgroup-add-rule
euca-delete-group secgroup-create
euca-describe-group secgroup-delete
euca-describe-groups secgroup-delete-group-rule
secgroup-delete-rule
secgroup-list
secgroup-list-rules

7. Example
Openstack EC2
$ nova secgroup-create mygroup description $ euca-add-group -d description mygroup
+---------+-------------+
| Name | Description | GROUP mygroup description
+---------+-------------+
| mygroup | description | $ euca-authorize -P tcp -s 192.168.1.0/24 -p 22 mygroup
+---------+-------------+ GROUP mygroup
$ nova secgroup-add-rule mygroup tcp 22 22 192.168.1.0/24
+-------------+-----------+---------+----------------+--------------+ PERMISSION mygroup ALLOWS tcp 22 22 FROM CIDR
| IP Protocol | From Port | To Port | IP Range | Source Group | 192.168.1.0/24
+-------------+-----------+---------+----------------+--------------+
| tcp | 22 | 22 | 192.168.1.0/24 | | $ euca-authorize -P tcp -s 192.168.1.0/24 -p 3306 mygroup
+-------------+-----------+---------+----------------+--------------+ GROUP mygroup
$ nova secgroup-add-rule mygroup tcp 3306 3306 192.168.1.0/24
+-------------+-----------+---------+----------------+--------------+ PERMISSION mygroup ALLOWS tcp 3306 3306 FROM CIDR
| IP Protocol | From Port | To Port | IP Range | Source Group | 192.168.1.0/24
+-------------+-----------+---------+----------------+--------------+
| tcp | 3306 | 3306 | 192.168.1.0/24 | | $ euca-describe-groups
+-------------+-----------+---------+----------------+--------------+
$ nova boot --flavor 1 –image f16f1d2d-71d6-41b7-98a5-319f142d61f5 --
GROUP 550d88112b9048fd931f1c66b2c7a932 default default
security_groups mygroup server1 GROUP 550d88112b9048fd931f1c66b2c7a932 mygroup description
+------------------------+--------------------------------------+ PERMISSION 550d88112b9048fd931f1c66b2c7a932 mygroup ALLOWS
| OS-DCF:diskConfig | MANUAL | tcp 22 22
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling | FROM CIDR 192.168.1.0/24
| OS-EXT-STS:vm_state | building | PERMISSION 550d88112b9048fd931f1c66b2c7a932 mygroup ALLOWS
| accessIPv4 | |
| accessIPv6 | | tcp 3306
| adminPass | 2QCHvG7fJ6Pc | 3306 FROM CIDR 192.168.1.0/24
| config_drive | |
| created | 2012-04-17T11:11:07Z | $ euca-run-instances tty -g mygroup
| flavor | m1.tiny |
| hostId | |
RESERVATION r-eezz74kc 550d88112b9048fd931f1c66b2c7a932
| id | 6d6bb47e-a356-4724-b48e-c248fceb1513 | mygroup
| image | cirros-0.3.0-x86_64-blank |
| key_name | |
INSTANCE i-00000001 ami-00000001 server-1 server-1
| metadata | {} | pending 0
| name | server1 | m1.small 2012-04-17T05:51:30.000Z unknown zone aki-
| progress | 0 |
| status | BUILD | 00000002
| tenant_id | 63c4cab49c8b449191d9ea5cfce0f928 | ari-00000003
| updated | 2012-04-17T11:11:08Z |
| user_id | d4dc81acfd604f72a56a70879fe565ad |
+------------------------+--------------------------------------+

8. Current Security Group Model
• Features:
– Per-Virtual Machine Security Group association
– Network egress filtering (network to VM)
– Matching on Source subnet, Protocol, and
Destination Port Range

9. Use Case: Distributed Firewall
(current features)

10. Use Case: Distributed Firewall
(current features)

11. Use Case: Distributed Firewall
(current features)

12. Security Group API
Verb URI Description
GET v1.1/{tenant_id}/os-security-groups List security groups
POST v1.1/{tenant_id}/os-security-groups Create a new security
group
GET v1.1/{tenant_id}/os-security- Get specific security group
groups/{security_group_id}
DELETE v1.1/{tenant_id}/os-security- Delete security group
groups/{security_group_id}
POST v1.1/{tenant_id}/os-security-group-rules Create security group rules
DELETE v1.1/{tenant_id}/os-security-group- Delete security group rule
rules/{security_group_rule_id}
GET v1.1/{tenant_id}/servers/{server_id}/os- List security groups for a
security-groups specific server

13. Proposed Security Group Model
• Features:
– Per-Port Security Group association
– Network egress/ingress filtering
• Similar to AWS VPC
– Matching on Source subnet, Protocol, and
Destination Port Range in both directions
– Stateful egress filtering
– Default deny except when no ingress
rules, then accept all on ingress
– IPv6 Support

14. Use Case: Distributed Firewall
(proposed features)

15. Proposed Security Group API
Verb URI Description
GET v1.1/{tenant_id}/os-security-groups List security groups
POST v1.1/{tenant_id}/os-security-groups Create a new security
group*
GET v1.1/{tenant_id}/os-security- Get specific security group
groups/{security_group_id}
DELETE v1.1/{tenant_id}/os-security- Delete security group
groups/{security_group_id}
PUT v1.1/{tenant_id}/os-security- Update security group*
groups/{security_group_id}
PUT v1.1/{tenant_id}/os-security- Associate port with
groups/{security_group_id}/associate_port security group
PUT v1.1/{tenant_id}/os-security- Dissociate port from
groups/{security_group_id}/dissociate_port security group
GET v1.1/{tenant_id}/os-security- List security groups for
groups/list_for_port specified port

16. Architecture

17. Pre-Essex Architecture

18. Essex Architecture

19. Folsom Architecture?

20. Other Features

21. Provider Firewalling
• Need to have security groups that are
modifiable by tenants
• Desirable to have security groups that are
only modifiable by service providers
– E.g. preventing a tenant from sending SMTP
traffic
– Blocking all incoming traffic on a known trojan
port
• Not ideal fit for security group

22. Access Control Lists
• Current security group model is
somewhat limited
• Would be nice to have a more generic
ACL capability
• Features:
– Ingress/Egress filtering
– Port-based association
– More sophisticated matching
– Allow/deny
– Combination of ACLs

23. Comments, Questions,
Suggestions?
@davlaps