I propose the following methods for security group management to be promoted and be a part of the standard / base compute API.
* ex_list_security_groups -> list_security_groups() Returns a list of class SecurityGroup * ex_create_security_groups -> create_security_group(name, **kwargs) We will use keyword arguments for this call as there are subtle differences between the providers (eg: groups within Amazon VPCs) * ex_authorize_security_group_ingress -> authorize_security_group_ingress(security_group, security_rule) Creates an ingress security group rule for a particular security group using a combination of protocol, to/from ports, and IP ranges or user group pairs. * ex_authorize_security_group_egress -> authorize_security_group_egress(security_rule) Creates an egress security group rule for a particular security group using a combination of protocol, to/from ports, and IP ranges or user group pairs. This will be used by both Amazon and CloudStack as OpenStack does not support egress rules. * ex_revoke_security_group_ingress -> revoke_security_group_ingress(security_rule) Revokes an ingress security group rule for a particular security group using a combination of protocol, to/from ports, and IP ranges or user group pairs. * ex_revoke_security_group_egress -> revoke_security_group_egress(security_rule) Revokes an egress security group rule for a particular security group using a combination of protocol, to/from ports, and IP ranges or user group pairs. This will be used by both Amazon and CloudStack as OpenStack does not support egress rules. * ex_delete_security_group -> delete_security_group(security_group) This will remove a security group using the ID which works across all providers. * ex_delete_security_group_by_id -> delete_security_group_by_id(security_group) Amazon and CloudStack support removing a group by the name or the ID which are mutually exclusive. We will support deletion using either. * ex_delete_security_group_by_name -> delete_security_group_by_name(security_group) Amazon and CloudStack support removing a group by the name or the ID which are mutually exclusive. We will support deletion using either. Supporting these calls means that new "SecurityGroup" and "SecurityGroupRule" classes which represent security groups and ingress/egress rules must be added. The proposal for these methods and classes are available as a gist via https://gist.github.com/cderamus/8182092 Currently, this functionality is already implemented as the aforementioned extension methods in the following drivers: * CloudStack * OpenStack * EC2 To preserve backward compatibility, we should also modify existing extension methods to call new methods and emit a deprecation warning. *Open questions* There are some differences between the various providers that will make this a bit complex. Here's some of the issues that I foresee and welcome feedback. 1.) Listing security groups for a particular node/instance becomes interesting. OpenStack has a specific call to list the security groups for a particular node which is already implemented in the driver. CloudStack appears to allow it using a filter when listing security groups and Amazon security groups can be applied to both a node, and in the case of a VPC, they can be applied to a particular network interface using the ModifyNetworkInterfaceAttribute call. There's really no clean way to support this so my guess is we should keep ex_ calls within the drivers themselves for this type of functionality. Thoughts? 2.) Security group rules git a bit dicey and I'm not sure how to best tackle the differences. Amazon/OpenStack are virtually identical and use from/to ports, IP protocols and CIDR ranges or user group pairs for the source. They use -1 to denote all protocols and if there is an ICMP type the type in question is put into the from/to port values. CloudStack supports TCP/UDP only as valid protocol values and actually has icmpcode/icmptype parameters that are used for ICMP rules. For the SecurityGroupRule class my thoughts were to make the protocol and from/to ports required parameters; however, CloudStack support may throw this off. Information on their request parameters can be found at http://goo.gl/Byxi4U .
