I haven't tried this mix and it was purely speculation from the API. Here's the specific line in the link:
"Name of the source security group. Cannot be used when specifying a CIDR IP address." "CIDR range. Cannot be used when specifying a source security group." Also, ec2-authorize ( http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html) doesn't allow the mix. If you made the call without an error, it's maybe wrong documentation. -- SM On Wed, Jul 6, 2011 at 11:23 PM, [email protected] <[email protected]>wrote: > On 07/07/11 00:16, Sang-Min Park wrote: > >> Marios, >> >> I looked at your aws patch (manage_security_group_**ingress) and wonder >> if you >> considered the limitation that either a cidr IP range or user-group pair >> can >> be given, not both. >> > > why? Or rather, how have you arrived at this conclusion? > > > > In other words, > >> >> source_ip_ranges.each_index do |i| >> call_params.merge!({"**IpPermissions.1.IpRanges.#{i+**1}.CidrIp" >> => >> source_ip_ranges[i].to_s}) >> end >> source_groups.each_index do |i| >> call_params.merge!({"**IpPermissions.1.Groups.#{i+1}.**GroupName" >> => >> source_groups[i]['group_name']**.to_s, >> "IpPermissions.1.Groups.#{i+1}**.UserId"=> >> source_groups[i]['owner'].to_**s.gsub(/-/,'')}) >> end >> >> If a user gives both source ip range and groups to the method, it may end >> up >> a request like this: >> >> &IpPermissions.1.IpProtocol=**tcp >> &IpPermissions.1.FromPort=80 >> &IpPermissions.1.ToPort=80 >> &IpPermissions.1.Groups.1.**GroupName=OtherAccountGroup >> &IpPermissions.1.Groups.1.**UserId=999988887777 >> &IpPermissions.1.IpRanges.1.**CidrIp=192.0.2.0/24 >> >> > Looks ok to me. Did you try this code and have trouble making a call with > these parameters (or were the effects of making such a call unexpected?) > > > > It doesn't look like a valid request according to the AWS definition ( >> http://docs.amazonwebservices.**com/AWSEC2/2011-01-01/** >> APIReference/index.html?**ApiReference-query-** >> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/APIReference/index.html?ApiReference-query-AuthorizeSecurityGroupIngress.html> >> ) >> >> > Interesting - but am unable to determine which part of the aws definition > makes the above a non-valid request? Can you be a little more specific > please? > > marios > > > Maybe I'm wrong? >> >> -- SM >> >> >> >> On Tue, Jun 28, 2011 at 4:24 PM, Sang-Min Park<sang-min.park@eucalyptus.* >> *com <[email protected]> >> >>> wrote: >>> >> >> Sorry marios for my late response. What I meant was not that Eucalyptus >>> driver supports firewall now, but the issue is there for me to implement >>> it. >>> Thanks for pointing out that AWS still has the old code. I'll use that >>> old >>> methods to implement firewalls against Eucalyptus. It will be uglier than >>> your code though (multiple AWS invocation as you imagine). >>> >>> -- SM >>> >>> >>> On Sun, Jun 26, 2011 at 11:06 PM, [email protected]<mandreou@** >>> redhat.com <[email protected]>>wrote: >>> >>> Hi Sang-Min, >>>> >>>> >>>> On 25/06/11 15:49, Sang-Min Park wrote: >>>> >>>> FYI, I looked at the firewall implementation and found that there's an >>>>> issue >>>>> with Eucalyptus driver. >>>>> >>>>> >>>> I was confused at first by what you meant as looking at Euca driver >>>> there's no mention of firewalls yet (besides the declaration of 'feature >>>> :instances, :firewalls') >>>> >>>> >>>> Eucalyptus supports the old parameter convention in >>>> >>>>> '****AuthorizeSecurityGroupIngress' action. I'll try if I can patch >>>>> AWS to >>>>> generate the old parameters as well as the new one. >>>>> >>>>> >>>> OK: you shouldn't need to patch aws at all - my additions to aws added >>>> the >>>> new 'manage_security_group_****ingress' method, BUT did not remove any >>>> of >>>> the old code. I'm not sure if thats what you meant by 'generate the old >>>> parameters as well as the new one' but if you mean that your Euca setup >>>> (or >>>> Euca in general) relies on the old appoxy/aws interface then your >>>> existing >>>> code should be fine - appoxy/aws gem has not removed any of those >>>> earlier >>>> methods: >>>> >>>> 1. authorize_security_group_****named_ingress >>>> 2. revoke_security_group_named_****ingress >>>> 3. authorize_security_group_IP_****ingress >>>> 4. revoke_security_group_IP_****ingress >>>> >>>> That being said, here's why I implemented the new >>>> 'manage_security_groups' >>>> method in the appoxy/aws gem: (https://github.com/appoxy/**** >>>> aws/pull/91 <https://github.com/appoxy/**aws/pull/91><https://github.** >>>> com/appoxy/aws/pull/91 <https://github.com/appoxy/aws/pull/91>>): >>>> >>>> methods 1/2 above don't allow you to specify fine-grained control over >>>> group >>>> access - i.e. you can specify which groups to authorize, but not which >>>> protocols/ports to allow for those groups. Also, 3/4 only allow you to >>>> specify a single IP range at a time - thus if a given firewall rule has >>>> a >>>> large number of address ranges then this operation will need to be done >>>> for >>>> each of those. Similarly, you can't specify both groups AND IP addresses >>>> in >>>> a single call (thus defining an entire firewall rule with a single >>>> call). >>>> >>>> The earlier implementations of appoxy/aws were based on the 2009 version >>>> of AWS API http://docs.amazonwebservices.****com/AWSEC2/2009-07-15/** >>>> APIReference/ApiReference-****query-****AuthorizeSecurityGroupIngress.* >>>> ***html<http://docs.**amazonwebservices.com/AWSEC2/** >>>> 2009-07-15/APIReference/**ApiReference-query-** >>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2009-07-15/APIReference/ApiReference-query-AuthorizeSecurityGroupIngress.html>>. >>>> In the latest version of API, you can specify a number of IP addresses, or >>>> >>>> groups, or mix of both, for which the specified rule will apply. You can >>>> now >>>> also specify 'from_port' 'to_port' and 'protocol' for ingress groups in >>>> a >>>> rule, >>>> >>>> marios >>>> >>>> >>>> >>>> >>>> >>>> >>>> Sang-min >>>>> >>>>> >>>>> >>>>> On Fri, Jun 17, 2011 at 8:06 AM,<[email protected]> wrote: >>>>> >>>>> >>>>> This patch uses the new 'Firewalls' collection (I pushed that to trunk >>>>>> today). >>>>>> The create_instance operation for the ec2 driver takes an array of >>>>>> firewall >>>>>> names >>>>>> for the instance to be 'launched into'. Patch includes: >>>>>> >>>>>> * necessary modifications to server.rb >>>>>> * addition of 'firewalls' to the Instance model >>>>>> * modification of the haml views: html for the create operation, >>>>>> html/xml >>>>>> for showing >>>>>> firewalls when inspecting a given instance. >>>>>> >>>>>> If you aren't using the html interface to create an instance, you can >>>>>> specify >>>>>> firewalls using form input : 'firewall#=name' where '#' is any digit. >>>>>> For >>>>>> example: >>>>>> >>>>>> curl -F 'image_id=ami-48aa4921' -F 'firewalls1=default' -F >>>>>> 'firewalls2=test' >>>>>> --user 'ec2_key:ec2_password' >>>>>> http://localhost:3001/api/****instances?format=xml<http://localhost:3001/api/**instances?format=xml> >>>>>> <http://**localhost:3001/api/instances?**format=xml<http://localhost:3001/api/instances?format=xml> >>>>>> > >>>>>> >>>>>> >>>>>> will create an instance from ami-48aa4921 and place it into firewalls >>>>>> 'default' >>>>>> and 'test'. EC2 does not support 'moving' an instance between >>>>>> firewalls >>>>>> once it's >>>>>> launched so this functionality was not implemented >>>>>> (http://aws.amazon.com/****articles/1145?_encoding=UTF8&****<http://aws.amazon.com/**articles/1145?_encoding=UTF8&**> >>>>>> jiveRedirect=1#13<http://aws.**amazon.com/articles/1145?_** >>>>>> encoding=UTF8&jiveRedirect=1#**13<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13> >>>>>> > >>>>>> ) >>>>>> >>>>>> marios >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- ---------------------------------------------------- Sang-Min Park Engineer Eucalyptus Systems
