Hey that's great news, thanks for providing this information sebgoa. This will definitely make things a bit easier.
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 > >
