You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by Sang-Min Park <sa...@eucalyptus.com> on 2011/07/06 23:16:34 UTC
Re: firewall support for ec2 instances
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. 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
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
)
Maybe I'm wrong?
-- SM
On Tue, Jun 28, 2011 at 4:24 PM, Sang-Min Park <sang-min.park@eucalyptus.com
> 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, marios@redhat.com <ma...@redhat.com>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,<ma...@redhat.com> 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
>>>>
>>>>
>>>
>>
>
--
----------------------------------------------------
Sang-Min Park
Engineer
Eucalyptus Systems
Re: firewall support for ec2 instances
Posted by "marios@redhat.com" <ma...@redhat.com>.
On 07/07/11 17:21, Sang-Min Park wrote:
> Here's answer from Mitch.
>
> ---------- Forwarded message ----------
> From: Mitch Garnaat<mi...@eucalyptus.com>
> Date: Thu, Jul 7, 2011 at 7:19 AM
> Subject: Re: AuthorizeSecurityGroupIngress
> To: Sang-Min Park<sa...@eucalyptus.com>
>
>
> Hi Sang-Min -
>
> It is true that you can specify both a group and a cidr on the
> AuthorizeSecurityGroupIngress request for EC2. However, EC2 silently
> ignores the cidr block and simply authorizes the group. To prove this, if
> you do a DescribeGroups request after the authorize request, you will see no
> mention of the cidr block in the group description.
>
Ok, well you made me doubt it enough to actually go try it out, *again*.
AuthorizeSecurityGroupIngress, using my 'manage_security_groups_ingress'
method in appoxy aws gem DOES work for a mix of IP address, and groups.
To make sure everything was in order I actually logged in to
aws.amazon.com/console to double check the security groups rules there.
Perhaps the behaviour that Mitch is describing was true in older
versions of the API. I don't know what else to say, besides I just did
this, and it works,
marios
> On Thu, Jul 7, 2011 at 7:01 AM, Sang-Min Park
> <sa...@eucalyptus.com>wrote:
>
>> It uses soap interface. Euca2ools (boto underneath) uses query interface
>> and quite popular.
>> I'll ask our tool master (Mitch who manages boto) if he's aware of this.
>>
>> -- SM
>>
>>
>> On Thu, Jul 7, 2011 at 6:52 AM, marios@redhat.com<ma...@redhat.com>wrote:
>>
>>> On 07/07/11 16:48, Sang-Min Park wrote:
>>>
>>>> I tried 'ec2-authorize' in the latest ec2-api-tools, and it doesn't allow
>>>> the mix.
>>>> Here's the output:
>>>> Specify either source groups or source CIDRs, not both. (-h for
>>>> usage)
>>>>
>>>> I could create a rule with multiple groups or a rule with multiple ip
>>>> range.
>>>> But I couldn't give -s [cidr] -o [group] option together.
>>>>
>>>> -- SM
>>>>
>>>
>>> thanks for trying that - well, that's very interesting indeed. I wonder
>>> why AWS allows this via the REST API but not via their own command line
>>> tools? This might be one for investigation for when I next get some idle
>>> time (e.g. what calls is the ec2-api-tools making? which interface is it
>>> using etc)
>>>
>>> marios
>>>
>>>
>>>
>>>>
>>>> On Thu, Jul 7, 2011 at 5:37 AM, marios@redhat.com<ma...@redhat.com>
>>>>> wrote:
>>>>
>>>> On 07/07/11 15:02, Sang-Min Park wrote:
>>>>>
>>>>> I haven't tried this mix and it was purely speculation from the API.
>>>>>>
>>>>>>
>>>>> ok
>>>>>
>>>>>
>>>>> 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."
>>>>>>
>>>>>>
>>>>>> yeah, ok i see now. This was also a source of confusion/frustration
>>>>> for me
>>>>> when i was writing the firewalls code. In the end I think this can just
>>>>> be
>>>>> taken literally - e.g. for 'name of the source group' : "you cannot use
>>>>> this
>>>>> parameter when specifying an IP address, since this refers to groups,
>>>>> not
>>>>> addresses".
>>>>>
>>>>>
>>>>> Also, ec2-authorize (
>>>>>
>>>>>> http://docs.amazonwebservices.****com/AWSEC2/2011-01-01/**
>>>>>> CommandLineReference/index.****html?ApiReference-cmd-**
>>>>>> AuthorizeSecurityGroupIngress.****html<http://docs.**
>>>>>> amazonwebservices.com/AWSEC2/**2011-01-01/**
>>>>>> CommandLineReference/index.**html?ApiReference-cmd-**
>>>>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html>
>>>>>>>
>>>>>>
>>>>>> )
>>>>>> doesn't allow the mix.
>>>>>>
>>>>>>
>>>>>> OK, this is interesting. First off, did you try this? What was the
>>>>> result?
>>>>> This line:
>>>>>
>>>>> "
>>>>> For EC2 security groups and ingress rules: This command either gives one
>>>>> or
>>>>> more CIDR IP address ranges permission to access a security group in
>>>>> your
>>>>> account, or it gives one or more security groups (
>>>>> "
>>>>>
>>>>> seems to suggest what you're saying. However, this line:
>>>>>
>>>>> "
>>>>> Each rule consists of the protocol (e.g., TCP), plus either a CIDR
>>>>> range,
>>>>> or a source group (for ingress rules) or destination group (for egress
>>>>> rules).
>>>>> "
>>>>>
>>>>> Note the use of 'a CIDR range' or 'a source group' - the plural is
>>>>> dropped;
>>>>> also, all the examples on that page seem to specify just a single
>>>>> source,
>>>>> either an address, or a group. *This* might be the reason that you can
>>>>> specify address OR ip, since you only specify one. Of course, this is
>>>>> all
>>>>> speculation, why don't you try this out and let us know the answer?
>>>>>
>>>>>
>>>>> If you made the call without an error, it's maybe wrong documentation.
>>>>>
>>>>>>
>>>>>>
>>>>> Of course I made the call - many, many times. I would never submit
>>>>> something for inclusion without it being tested first, not least because
>>>>> this code was a contribution to a another project (the appoxy aws gem).
>>>>> The
>>>>> question however should be turned on its head - did you make the call,
>>>>> and
>>>>> did it cause the error that you are reporting here?
>>>>>
>>>>> marios
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- SM
>>>>>>
>>>>>> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<mandreou@**r**
>>>>>> edhat.com<ht...@redhat.com>
>>>>>>
>>>>>> 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.**<http://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<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<sa...@eucalyptus.com>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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, marios@redhat.com<mandreou@**
>>>>>>>>> redhat.com<mandreou@redhat.com****>>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/********<https://github.com/appoxy/******>
>>>>>>>>>> <https://github.com/appoxy/******<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>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> <http**s://github.<https://**github<https://github>.>**
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> com/appoxy/aws/pull/91<https:/****/github.com/appoxy/aws/pull/**91<http://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.****amazonwe**bservices.com/**AWSEC2/**<http://bservices.com/AWSEC2/**>
>>>>>>>>>> <http://**amazonwebservices.com/AWSEC2/****<http://amazonwebservices.com/AWSEC2/**>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009-07-15/APIReference/******ApiReference-query-**
>>>>>>>>>> AuthorizeSecurityGroupIngress.******html<http://docs.**
>>>>>>>>>> amazonwebservices.com/AWSEC2/****2009-07-15/APIReference/**<http://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,<ma...@redhat.com> 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>
>>>>>>>>>>>>>
>>>>>>>>>>>> <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<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&******>
>>>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=**UTF8&****<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=UTF8&******<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>>>> <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?_***
>>>>>>>>>>>> *<http://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<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> )
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> marios
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> ----------------------------------------------------
>> Sang-Min Park
>> Engineer
>> Eucalyptus Systems
>>
>>
>
>
Re: firewall support for ec2 instances
Posted by Sang-Min Park <sa...@eucalyptus.com>.
Here's answer from Mitch.
---------- Forwarded message ----------
From: Mitch Garnaat <mi...@eucalyptus.com>
Date: Thu, Jul 7, 2011 at 7:19 AM
Subject: Re: AuthorizeSecurityGroupIngress
To: Sang-Min Park <sa...@eucalyptus.com>
Hi Sang-Min -
It is true that you can specify both a group and a cidr on the
AuthorizeSecurityGroupIngress request for EC2. However, EC2 silently
ignores the cidr block and simply authorizes the group. To prove this, if
you do a DescribeGroups request after the authorize request, you will see no
mention of the cidr block in the group description.
On Thu, Jul 7, 2011 at 7:01 AM, Sang-Min Park
<sa...@eucalyptus.com>wrote:
> It uses soap interface. Euca2ools (boto underneath) uses query interface
> and quite popular.
> I'll ask our tool master (Mitch who manages boto) if he's aware of this.
>
> -- SM
>
>
> On Thu, Jul 7, 2011 at 6:52 AM, marios@redhat.com <ma...@redhat.com>wrote:
>
>> On 07/07/11 16:48, Sang-Min Park wrote:
>>
>>> I tried 'ec2-authorize' in the latest ec2-api-tools, and it doesn't allow
>>> the mix.
>>> Here's the output:
>>> Specify either source groups or source CIDRs, not both. (-h for
>>> usage)
>>>
>>> I could create a rule with multiple groups or a rule with multiple ip
>>> range.
>>> But I couldn't give -s [cidr] -o [group] option together.
>>>
>>> -- SM
>>>
>>
>> thanks for trying that - well, that's very interesting indeed. I wonder
>> why AWS allows this via the REST API but not via their own command line
>> tools? This might be one for investigation for when I next get some idle
>> time (e.g. what calls is the ec2-api-tools making? which interface is it
>> using etc)
>>
>> marios
>>
>>
>>
>>>
>>> On Thu, Jul 7, 2011 at 5:37 AM, marios@redhat.com<ma...@redhat.com>
>>> >wrote:
>>>
>>> On 07/07/11 15:02, Sang-Min Park wrote:
>>>>
>>>> I haven't tried this mix and it was purely speculation from the API.
>>>>>
>>>>>
>>>> ok
>>>>
>>>>
>>>> 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."
>>>>>
>>>>>
>>>>> yeah, ok i see now. This was also a source of confusion/frustration
>>>> for me
>>>> when i was writing the firewalls code. In the end I think this can just
>>>> be
>>>> taken literally - e.g. for 'name of the source group' : "you cannot use
>>>> this
>>>> parameter when specifying an IP address, since this refers to groups,
>>>> not
>>>> addresses".
>>>>
>>>>
>>>> Also, ec2-authorize (
>>>>
>>>>> http://docs.amazonwebservices.****com/AWSEC2/2011-01-01/**
>>>>> CommandLineReference/index.****html?ApiReference-cmd-**
>>>>> AuthorizeSecurityGroupIngress.****html<http://docs.**
>>>>> amazonwebservices.com/AWSEC2/**2011-01-01/**
>>>>> CommandLineReference/index.**html?ApiReference-cmd-**
>>>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html>
>>>>> >
>>>>>
>>>>> )
>>>>> doesn't allow the mix.
>>>>>
>>>>>
>>>>> OK, this is interesting. First off, did you try this? What was the
>>>> result?
>>>> This line:
>>>>
>>>> "
>>>> For EC2 security groups and ingress rules: This command either gives one
>>>> or
>>>> more CIDR IP address ranges permission to access a security group in
>>>> your
>>>> account, or it gives one or more security groups (
>>>> "
>>>>
>>>> seems to suggest what you're saying. However, this line:
>>>>
>>>> "
>>>> Each rule consists of the protocol (e.g., TCP), plus either a CIDR
>>>> range,
>>>> or a source group (for ingress rules) or destination group (for egress
>>>> rules).
>>>> "
>>>>
>>>> Note the use of 'a CIDR range' or 'a source group' - the plural is
>>>> dropped;
>>>> also, all the examples on that page seem to specify just a single
>>>> source,
>>>> either an address, or a group. *This* might be the reason that you can
>>>> specify address OR ip, since you only specify one. Of course, this is
>>>> all
>>>> speculation, why don't you try this out and let us know the answer?
>>>>
>>>>
>>>> If you made the call without an error, it's maybe wrong documentation.
>>>>
>>>>>
>>>>>
>>>> Of course I made the call - many, many times. I would never submit
>>>> something for inclusion without it being tested first, not least because
>>>> this code was a contribution to a another project (the appoxy aws gem).
>>>> The
>>>> question however should be turned on its head - did you make the call,
>>>> and
>>>> did it cause the error that you are reporting here?
>>>>
>>>> marios
>>>>
>>>>
>>>>
>>>>
>>>> -- SM
>>>>>
>>>>> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<mandreou@**r**
>>>>> edhat.com <ht...@redhat.com>
>>>>>
>>>>> 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.**<http://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<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<sa...@eucalyptus.com>
>>>>>>> >>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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, marios@redhat.com<mandreou@**
>>>>>>>> redhat.com<mandreou@redhat.com****>>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/********<https://github.com/appoxy/******>
>>>>>>>>> <https://github.com/appoxy/****** <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>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>> <http**s://github.<https://**github <https://github>.>**
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> com/appoxy/aws/pull/91<https:/****/github.com/appoxy/aws/pull/**91<http://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.****amazonwe**bservices.com/**AWSEC2/**<http://bservices.com/AWSEC2/**>
>>>>>>>>> <http://**amazonwebservices.com/AWSEC2/****<http://amazonwebservices.com/AWSEC2/**>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> 2009-07-15/APIReference/******ApiReference-query-**
>>>>>>>>> AuthorizeSecurityGroupIngress.******html<http://docs.**
>>>>>>>>> amazonwebservices.com/AWSEC2/****2009-07-15/APIReference/**<http://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,<ma...@redhat.com> 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>
>>>>>>>>>>> >
>>>>>>>>>>> <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<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&******>
>>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=**UTF8&****<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=UTF8&******<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>>> <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?_***
>>>>>>>>>>> * <http://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<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> )
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> marios
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
> --
>
> ----------------------------------------------------
> Sang-Min Park
> Engineer
> Eucalyptus Systems
>
>
--
----------------------------------------------------
Sang-Min Park
Engineer
Eucalyptus Systems
Re: firewall support for ec2 instances
Posted by Sang-Min Park <sa...@eucalyptus.com>.
It uses soap interface. Euca2ools (boto underneath) uses query interface and
quite popular.
I'll ask our tool master (Mitch who manages boto) if he's aware of this.
-- SM
On Thu, Jul 7, 2011 at 6:52 AM, marios@redhat.com <ma...@redhat.com>wrote:
> On 07/07/11 16:48, Sang-Min Park wrote:
>
>> I tried 'ec2-authorize' in the latest ec2-api-tools, and it doesn't allow
>> the mix.
>> Here's the output:
>> Specify either source groups or source CIDRs, not both. (-h for
>> usage)
>>
>> I could create a rule with multiple groups or a rule with multiple ip
>> range.
>> But I couldn't give -s [cidr] -o [group] option together.
>>
>> -- SM
>>
>
> thanks for trying that - well, that's very interesting indeed. I wonder why
> AWS allows this via the REST API but not via their own command line tools?
> This might be one for investigation for when I next get some idle time (e.g.
> what calls is the ec2-api-tools making? which interface is it using etc)
>
> marios
>
>
>
>>
>> On Thu, Jul 7, 2011 at 5:37 AM, marios@redhat.com<ma...@redhat.com>
>> >wrote:
>>
>> On 07/07/11 15:02, Sang-Min Park wrote:
>>>
>>> I haven't tried this mix and it was purely speculation from the API.
>>>>
>>>>
>>> ok
>>>
>>>
>>> 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."
>>>>
>>>>
>>>> yeah, ok i see now. This was also a source of confusion/frustration for
>>> me
>>> when i was writing the firewalls code. In the end I think this can just
>>> be
>>> taken literally - e.g. for 'name of the source group' : "you cannot use
>>> this
>>> parameter when specifying an IP address, since this refers to groups, not
>>> addresses".
>>>
>>>
>>> Also, ec2-authorize (
>>>
>>>> http://docs.amazonwebservices.****com/AWSEC2/2011-01-01/**
>>>> CommandLineReference/index.****html?ApiReference-cmd-**
>>>> AuthorizeSecurityGroupIngress.****html<http://docs.**
>>>> amazonwebservices.com/AWSEC2/**2011-01-01/**CommandLineReference/index.
>>>> **html?ApiReference-cmd-**AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html>
>>>> >
>>>>
>>>> )
>>>> doesn't allow the mix.
>>>>
>>>>
>>>> OK, this is interesting. First off, did you try this? What was the
>>> result?
>>> This line:
>>>
>>> "
>>> For EC2 security groups and ingress rules: This command either gives one
>>> or
>>> more CIDR IP address ranges permission to access a security group in your
>>> account, or it gives one or more security groups (
>>> "
>>>
>>> seems to suggest what you're saying. However, this line:
>>>
>>> "
>>> Each rule consists of the protocol (e.g., TCP), plus either a CIDR range,
>>> or a source group (for ingress rules) or destination group (for egress
>>> rules).
>>> "
>>>
>>> Note the use of 'a CIDR range' or 'a source group' - the plural is
>>> dropped;
>>> also, all the examples on that page seem to specify just a single source,
>>> either an address, or a group. *This* might be the reason that you can
>>> specify address OR ip, since you only specify one. Of course, this is all
>>> speculation, why don't you try this out and let us know the answer?
>>>
>>>
>>> If you made the call without an error, it's maybe wrong documentation.
>>>
>>>>
>>>>
>>> Of course I made the call - many, many times. I would never submit
>>> something for inclusion without it being tested first, not least because
>>> this code was a contribution to a another project (the appoxy aws gem).
>>> The
>>> question however should be turned on its head - did you make the call,
>>> and
>>> did it cause the error that you are reporting here?
>>>
>>> marios
>>>
>>>
>>>
>>>
>>> -- SM
>>>>
>>>> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<mandreou@**r**
>>>> edhat.com <ht...@redhat.com>
>>>>
>>>> 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.**<http://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<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<sa...@eucalyptus.com>
>>>>>> >>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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, marios@redhat.com<mandreou@**
>>>>>>> redhat.com<mandreou@redhat.com****>>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/********<https://github.com/appoxy/******>
>>>>>>>> <https://github.com/appoxy/****** <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>
>>>>>>>> >
>>>>>>>>
>>>>>>>>> <http**s://github.<https://**github <https://github>.>**
>>>>>>>>>
>>>>>>>>
>>>>>>>> com/appoxy/aws/pull/91<https:/****/github.com/appoxy/aws/pull/**91<http://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.****amazonwe**bservices.com/**AWSEC2/**<http://bservices.com/AWSEC2/**>
>>>>>>>> <http://**amazonwebservices.com/AWSEC2/****<http://amazonwebservices.com/AWSEC2/**>
>>>>>>>> >
>>>>>>>>
>>>>>>>> 2009-07-15/APIReference/******ApiReference-query-**
>>>>>>>> AuthorizeSecurityGroupIngress.******html<http://docs.**
>>>>>>>> amazonwebservices.com/AWSEC2/****2009-07-15/APIReference/**<http://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,<ma...@redhat.com> 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>
>>>>>>>>>> >
>>>>>>>>>> <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<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&******>
>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=**UTF8&****<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=UTF8&******<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>> <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?_****<http://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<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> )
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> marios
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
----------------------------------------------------
Sang-Min Park
Engineer
Eucalyptus Systems
Re: firewall support for ec2 instances
Posted by "marios@redhat.com" <ma...@redhat.com>.
On 07/07/11 16:48, Sang-Min Park wrote:
> I tried 'ec2-authorize' in the latest ec2-api-tools, and it doesn't allow
> the mix.
> Here's the output:
> Specify either source groups or source CIDRs, not both. (-h for usage)
>
> I could create a rule with multiple groups or a rule with multiple ip range.
> But I couldn't give -s [cidr] -o [group] option together.
>
> -- SM
thanks for trying that - well, that's very interesting indeed. I wonder
why AWS allows this via the REST API but not via their own command line
tools? This might be one for investigation for when I next get some idle
time (e.g. what calls is the ec2-api-tools making? which interface is it
using etc)
marios
>
>
> On Thu, Jul 7, 2011 at 5:37 AM, marios@redhat.com<ma...@redhat.com>wrote:
>
>> On 07/07/11 15:02, Sang-Min Park wrote:
>>
>>> I haven't tried this mix and it was purely speculation from the API.
>>>
>>
>> ok
>>
>>
>> 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."
>>>
>>>
>> yeah, ok i see now. This was also a source of confusion/frustration for me
>> when i was writing the firewalls code. In the end I think this can just be
>> taken literally - e.g. for 'name of the source group' : "you cannot use this
>> parameter when specifying an IP address, since this refers to groups, not
>> addresses".
>>
>>
>> Also, ec2-authorize (
>>> http://docs.amazonwebservices.**com/AWSEC2/2011-01-01/**
>>> CommandLineReference/index.**html?ApiReference-cmd-**
>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html>
>>> )
>>> doesn't allow the mix.
>>>
>>>
>> OK, this is interesting. First off, did you try this? What was the result?
>> This line:
>>
>> "
>> For EC2 security groups and ingress rules: This command either gives one or
>> more CIDR IP address ranges permission to access a security group in your
>> account, or it gives one or more security groups (
>> "
>>
>> seems to suggest what you're saying. However, this line:
>>
>> "
>> Each rule consists of the protocol (e.g., TCP), plus either a CIDR range,
>> or a source group (for ingress rules) or destination group (for egress
>> rules).
>> "
>>
>> Note the use of 'a CIDR range' or 'a source group' - the plural is dropped;
>> also, all the examples on that page seem to specify just a single source,
>> either an address, or a group. *This* might be the reason that you can
>> specify address OR ip, since you only specify one. Of course, this is all
>> speculation, why don't you try this out and let us know the answer?
>>
>>
>> If you made the call without an error, it's maybe wrong documentation.
>>>
>>
>> Of course I made the call - many, many times. I would never submit
>> something for inclusion without it being tested first, not least because
>> this code was a contribution to a another project (the appoxy aws gem). The
>> question however should be turned on its head - did you make the call, and
>> did it cause the error that you are reporting here?
>>
>> marios
>>
>>
>>
>>
>>> -- SM
>>>
>>> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<ma...@redhat.com>
>>>> 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<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<sa...@eucalyptus.com>>
>>>>>
>>>>>
>>>>> 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, marios@redhat.com<mandreou@**
>>>>>> redhat.com<mandreou@redhat.com**>>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/******<https://github.com/appoxy/****>
>>>>>>> aws/pull/91<https://github.**com/appoxy/**aws/pull/91<https://github.com/appoxy/**aws/pull/91>
>>>>>>>> <http**s://github.<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.**amazonwe**bservices.com/AWSEC2/**<http://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,<ma...@redhat.com> 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>
>>>>>>>>>>
>>>>>>>>> <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&****>
>>>>>>>>> <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<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> )
>>>>>>>>>
>>>>>>>>> marios
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: firewall support for ec2 instances
Posted by Sang-Min Park <sa...@eucalyptus.com>.
I tried 'ec2-authorize' in the latest ec2-api-tools, and it doesn't allow
the mix.
Here's the output:
Specify either source groups or source CIDRs, not both. (-h for usage)
I could create a rule with multiple groups or a rule with multiple ip range.
But I couldn't give -s [cidr] -o [group] option together.
-- SM
On Thu, Jul 7, 2011 at 5:37 AM, marios@redhat.com <ma...@redhat.com>wrote:
> On 07/07/11 15:02, Sang-Min Park wrote:
>
>> I haven't tried this mix and it was purely speculation from the API.
>>
>
> ok
>
>
> 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."
>>
>>
> yeah, ok i see now. This was also a source of confusion/frustration for me
> when i was writing the firewalls code. In the end I think this can just be
> taken literally - e.g. for 'name of the source group' : "you cannot use this
> parameter when specifying an IP address, since this refers to groups, not
> addresses".
>
>
> Also, ec2-authorize (
>> http://docs.amazonwebservices.**com/AWSEC2/2011-01-01/**
>> CommandLineReference/index.**html?ApiReference-cmd-**
>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html>
>> )
>> doesn't allow the mix.
>>
>>
> OK, this is interesting. First off, did you try this? What was the result?
> This line:
>
> "
> For EC2 security groups and ingress rules: This command either gives one or
> more CIDR IP address ranges permission to access a security group in your
> account, or it gives one or more security groups (
> "
>
> seems to suggest what you're saying. However, this line:
>
> "
> Each rule consists of the protocol (e.g., TCP), plus either a CIDR range,
> or a source group (for ingress rules) or destination group (for egress
> rules).
> "
>
> Note the use of 'a CIDR range' or 'a source group' - the plural is dropped;
> also, all the examples on that page seem to specify just a single source,
> either an address, or a group. *This* might be the reason that you can
> specify address OR ip, since you only specify one. Of course, this is all
> speculation, why don't you try this out and let us know the answer?
>
>
> If you made the call without an error, it's maybe wrong documentation.
>>
>
> Of course I made the call - many, many times. I would never submit
> something for inclusion without it being tested first, not least because
> this code was a contribution to a another project (the appoxy aws gem). The
> question however should be turned on its head - did you make the call, and
> did it cause the error that you are reporting here?
>
> marios
>
>
>
>
>> -- SM
>>
>> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<ma...@redhat.com>
>> >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<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<sang-min.park@eucalyptus.**com <sa...@eucalyptus.com>>
>>>>
>>>>
>>>> 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, marios@redhat.com<mandreou@**
>>>>> redhat.com<mandreou@redhat.com**>>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/******<https://github.com/appoxy/****>
>>>>>> aws/pull/91<https://github.**com/appoxy/**aws/pull/91<https://github.com/appoxy/**aws/pull/91>
>>>>>> ><http**s://github. <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.**amazonwe**bservices.com/AWSEC2/**<http://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,<ma...@redhat.com> 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>
>>>>>>>> >
>>>>>>>> <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&****>
>>>>>>>> <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<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>> )
>>>>>>>>
>>>>>>>> marios
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
----------------------------------------------------
Sang-Min Park
Engineer
Eucalyptus Systems
Re: firewall support for ec2 instances
Posted by "marios@redhat.com" <ma...@redhat.com>.
On 07/07/11 15:02, Sang-Min Park wrote:
> I haven't tried this mix and it was purely speculation from the API.
ok
> 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."
>
yeah, ok i see now. This was also a source of confusion/frustration for
me when i was writing the firewalls code. In the end I think this can
just be taken literally - e.g. for 'name of the source group' : "you
cannot use this parameter when specifying an IP address, since this
refers to groups, not addresses".
> Also, ec2-authorize (
> http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html)
> doesn't allow the mix.
>
OK, this is interesting. First off, did you try this? What was the
result? This line:
"
For EC2 security groups and ingress rules: This command either gives one
or more CIDR IP address ranges permission to access a security group in
your account, or it gives one or more security groups (
"
seems to suggest what you're saying. However, this line:
"
Each rule consists of the protocol (e.g., TCP), plus either a CIDR
range, or a source group (for ingress rules) or destination group (for
egress rules).
"
Note the use of 'a CIDR range' or 'a source group' - the plural is
dropped; also, all the examples on that page seem to specify just a
single source, either an address, or a group. *This* might be the reason
that you can specify address OR ip, since you only specify one. Of
course, this is all speculation, why don't you try this out and let us
know the answer?
> If you made the call without an error, it's maybe wrong documentation.
Of course I made the call - many, many times. I would never submit
something for inclusion without it being tested first, not least because
this code was a contribution to a another project (the appoxy aws gem).
The question however should be turned on its head - did you make the
call, and did it cause the error that you are reporting here?
marios
>
> -- SM
>
> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<ma...@redhat.com>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<sa...@eucalyptus.com>
>>>
>>>> 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, marios@redhat.com<mandreou@**
>>>> redhat.com<ma...@redhat.com>>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,<ma...@redhat.com> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: firewall support for ec2 instances
Posted by Sang-Min Park <sa...@eucalyptus.com>.
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, marios@redhat.com <ma...@redhat.com>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 <sa...@eucalyptus.com>
>>
>>> 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, marios@redhat.com<mandreou@**
>>> redhat.com <ma...@redhat.com>>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,<ma...@redhat.com> 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
Re: firewall support for ec2 instances
Posted by "marios@redhat.com" <ma...@redhat.com>.
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<sang-min.park@eucalyptus.com
>> 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, marios@redhat.com<ma...@redhat.com>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,<ma...@redhat.com> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
>