The gist has been updated at https://gist.github.com/cderamus/8182092 and is ready for review. If desired, we could add a direction parameter to the authorize/revoke methods to specify a direction (ingress vs. egress). The reason I kept them separate was mainly just because I thought calling out the direction in the method name made it more obvious what it was doing.
@Tomaz. You asked if revoking the rule just required the ID. For OpenStack that is correct, but AWS revokes the rule based on the source, protocol and to/from port values. They don't use IDs at all. On Mon, Jan 6, 2014 at 8:08 AM, sebgoa <[email protected]> wrote: > > On Jan 6, 2014, at 2:03 PM, Chris DeRamus <[email protected]> wrote: > > > Hey that's great news, thanks for providing this information sebgoa. This > > will definitely make things a bit easier. > > > > I also have the missing methods for the cloudstack driver in a local > branch but I did not push them cause they lack test/fixtures. > > -sebastien > > > > > On Mon, Jan 6, 2014 at 7:57 AM, sebgoa <[email protected]> wrote: > > > >> > >> 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 > >> > >> > >
