On Dec 30, 2013, at 9:47 PM, Chris DeRamus <[email protected]> wrote:
> 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? Hi, you can list security groups for a particular instance in CloudStack using the virtualmachineid argument: http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/listSecurityGroups.html > > 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 > . Actually this will work fine, I just tested it and it seems to be a bug in the apidoc, ICMP is supported in the protocol field. But CloudStack will need to know the type of icmp packets allowed (type and code). FYI, the latest doc is at: http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/authorizeSecurityGroupIngress.html
