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
)


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<[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]<[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>):
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>.
 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>

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&**
jiveRedirect=1#13<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
)

marios








Reply via email to