[chef] Re: Re: Re: Re: Re: why does mysql on ec2 bind to priviate i.p?

[Jeffrey Hulten < >]

Without going too off topic, I usually don't use default for that very 
reason. Also having monitoring rules to watch the settings of your security 
groups (and vpcs and elbs…) is a good plan.

I should really add to the AWS cookbook to support converging SGs...

--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC

 
  206-853-5216
Skype: jeffhulten

On Nov 14, 2012, at 12:36 PM, Charles Johnson wrote:

> I'm certainly not trying to spread any FUD about security and EC2.
> Security groups are great, I'm a huge fan! Use them!
> 
> That said, you might be amazed at how many times Helpful Friendly Junior
> Sysadmin has just added every machine to the default security group, and
> then enabled 3306 TCP. This is clearly insane behavior.
> 
> But the point of a sane default is to keep things operating in a
> predictable, reliable, & secure fashion, even when people do insane
> things. In this case, compounding potential user insanity by default
> binding mysql to 0.0.0.0 would be the most predictable behavior, but also
> the least reliable or safe.
> 
> To my mind, defaulting to reliability and safety over predictability in
> this case is the most sane course of action. Thus my voicing support for
> the current default setting in the mysql cookbook.
> 
> Thanks,
>       --Charles
> 
> -- 
> On 11/14/12 11:09 AM, "Jeffrey Hulten" 
> <
 >
>  wrote:
> 
> 
>> Your other instances cannot access each other unless one of their
>> security groups is allowed inbound access. The default SG is configured
>> this way.
>> 
>> There is a lot of FUD about security and EC2. Remember that what you have
>> is a software based firewall controlling ingress to your box. Your
>> packets share wires with other packets, even if you can't see them.
>> 
>> If you think there are issues with AWS security groups then by all means
>> add iptables to your hosts and limit access that way.
>> 
>> Also, if you have that level of security requirements you should probably
>> be using ssl to protect your data in transit.
>> http://dev.mysql.com/doc/refman/5.6/en/ssl-connections.html
>> 
>> 
>> 
>> --
>> Jeffrey Hulten
>> Principal Consultant at Automated Labs, LLC
>> 
 
>>   206-853-5216
>> Skype: jeffhulten
>> 
>> On Nov 14, 2012, at 10:26 AM, S Ahmed wrote:
>> 
>>> Thanks, I'll look into this further so it sinks in :)
>>> 
>>> BTW, why is ec2 inherently  not secure?  The default security group
>>> doesn't have 3306 open anyhow, so you wouldn't be mooning the entire
>>> world per say, only your other instances (which I believe by default all
>>> your other instances can access).
>>> 
>>> 
>>> On Wed, Nov 14, 2012 at 12:04 PM, Charles Johnson 
>>> <
 >
>>> wrote:
>>> The real problem here is an outdated limitation in mysql.
>>> 
>>> Unfortunately, mysql only takes one bind-address argument rather than
>>> an array, so it's impossible to listen on a limited subset of local
>>> addresses. You may decide to have mysql listen on all bound IP
>>> addresses, or one and only one bound IP address, but you many not listen
>>> a subset of all bound IP addresses (unless you bring local firewalls
>>> into the picture, but that's another discussion).
>>> 
>>> When running in an inherently insecure environment such as EC2, binding
>>> to 0.0.0.0 and allowing connections from any host is an unacceptable
>>> default. This leaves an unfortunate dilemma: Either bind to the private
>>> IP address and disallow traffic from localhost, or bind to localhost and
>>> only allow traffic from self.
>>> 
>>> If the default is to bind to localhost, this will cause countless hours
>>> of frustration as people try to figure out why the database isn't
>>> accessible from their external servers out of the box. However, since
>>> it's possible for a node in EC2 to access its own private IP address and
>>> resolve it to a hostname, the default that arguably solves the most
>>> problems and creates the least frustration is to bind to the private IP
>>> address.
>>> 
>>> Many people get around this problem by using unix sockets for
>>> communication to mysql if they're running the app and database on the
>>> same node. Unfortunately in your case, JDBC is 100% TCP/IP and doesn't
>>> support unix sockets. The solution for you is either to override the
>>> cookbook's default bind_address to 127.0.0.1, or to use a template to
>>> get the hostname into your application's config file instead of
>>> localhost.
>>> 
>>> tl;dr: The default behavior of the cookbook is sane, even though it's
>>> inconvenient for many use cases. You'll need to override the cookbook's
>>> default attribute back to localhost, or address the database via the
>>> hostname instead of localhost.
>>> 
>>> Thanks,
>>> --Charles
>>> 
>>> 
>>> From: S Ahmed 
>>> <
 >
>>> Reply-To: 
>>> "
 "
>>>  
>>> <
 >
>>> Date: Wednesday, November 14, 2012 8:33 AM
>>> To: 
>>> "
 "
>>>  
>>> <
 >
>>> Subject: [chef] Re: Re: why does mysql on ec2 bind to priviate i.p?
>>> 
>>> If I set it to 127.0.0.1, does this mean I can't access it from another
>>> ec2 server then?
>>> 
>>> The problem is during deployment, I don't know the private i.p in
>>> advance and during deployment all my database configuration information
>>> has 'localhost' in it.  I understand what you guys are saying and it
>>> does make sense, I just have to modify my deployment process to first
>>> pull in the private ip's for each service (I should be doing this anyhow
>>> as eventually not everything is going to fit on a single instance!)
>>> 
>>> 
>>> On Wed, Nov 14, 2012 at 9:26 AM, Joshua Timberman 
>>> <
 >
>>> wrote:
>>> On 11/13/12 9:28 PM, "S Ahmed" 
>>> <
 >
>>>  wrote:
>>> 
>>> 
>>>> I noticed when I used the mysql recipe it installs mysql and binds it
>>> to
>>>> the private i.p on ec2, why is that?
>>>> 
>>>> My application can't connect as it uses 'localhost' (jdbc), but for
>>> some
>>>> reason it works fine using ruby.
>>> 
>>> The reason for not using localhost is because in the opinion of the
>>> cookbook, it is more useful to have the server accessible on the
>>> [private]
>>> network so that other systems like application servers can connect to
>>> it.
>>> We use the private address on cloud providers because, as Matt pointed
>>> out, it may cost money for external bandwidth. Also, having your
>>> database
>>> server accessible on the external network is bad :).
>>> 
>>> You can set the attribute `node['mysql']['bind_address']` in a role or
>>> on
>>> the node itself, to use loopback.
>>> 
>>> 
>>> For example, in a role:
>>> 
>>> default_attributes(
>>>  "mysql" => {
>>>    "bind_address" => "127.0.0.1"
>>>  }
>>> )
>>> 
>>> On the node itself would be the JSON equivalent of the above.
>>> 
>>> 
>>> 
>>> 
>> 
> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail