Per this, Cloud SQL requires the external IP address of the client in order to allow connections to it. The other suggested way is the sql proxy with a big disclaimer that the method may change over time.
Question: If I am auto scaling compute engine VMs running webservers, do I need to assign them all external IPs and then go set those in the Cloud SQL instance? Or am I missing something huge? Noob question perhaps, thanks for reading through.
The recommended way is to use the Cloud SQL proxy (but if you really don't want to use it you would need to add static IPs to your GCE VMs and whitelist them on the Cloud SQL instance).
Also, you can setup a single VM instance with cloud_sql_proxy and listen to your subnet interface (for example) to make possible to connect any new VM instance to the one with a proxy.
Related
Currently I am using the native Cloud SQL instance that is getting billed against the same project. However to cut some cost, I intend to shift the databases to my other mysql sitting at my other hosting. But I need to put a static IP on the allowed hosts in order to make it work. I added the 4 hosts that they make you add as A records to point the domain. But it didn't work. I read about Sockets API.. but didn't really get it. It's confusing. How to make it work? putting those 4 IP in makes it workable once or twice randomly when once of those provided IP is active I guess but whenever some other IP from the pool gets active, it doesn't work!
Have you looked at Serverless VPC Access with VPC Access Connector as described here?
You should be able to use the VPC Access Connector Source IP CIDR range at your MySql end as allowed IP list.
However you must ensure the connection is secure with a VPN or interconnect.
I am writing an AWS Lambda function to connect to a MySQL instance running on EC2. I have associated the Lambda function with the same subnet and security group that the EC2 is configured in. I checked the Lambda function's IAM roles and that has AWSLambdaVPCAccessExecutionRole policy attached to it. However I am still not able to connect to the MySQL instance.
I tried allowing traffic from anywhere and that worked but now I am not sure how to connect to the MySQL instance with stricter security rules.
I am using Kotlin to write my lambda function and using serverless to deploy changes to lambda.
I have tried every possible solution available online to make this happen but I haven't had any positive results yet.
You have associated the Lambda function with the same security group. But just that would not do. You also need to add an ingress rule to allow traffic to the security group from itself. Basically, you need to self reference the security group.
Add a rule to allow traffic on the mysql port from sg-xxxxxxxx.
Lets say I have a VM instance and I then make a connection to the Cloud SQL instances IP using a MySQL client. According to the comparison table in Connection Options for External Applications, connecting with no SSL is apparently not secure (and non-encrypted).
But to what extent is it insecure? If there is a man-in-the-middle attack, query and query results could be seen. I would like to determine how big of a risk that is.
Specifically I would like to know the risks of connecting from:
A VM in the exact same zone to a Cloud SQL instance
A VM in the same region, but a difference zone to a Cloud SQL instance
A VM in another region to a Cloud SQL instance, but still from GCP
I assume that for any of these kinds of attacks to be carried out, the actual google infrastructure would have to have been compromised as it wouldn't be possible for a VM to listen to traffic outside a network that it's attached to.
The actual infrastructure wouldn't have to be compromised actually, all that it'd take is for an instance in the same network to be compromised for the details of your connection to Cloud SQL to potentially be compromised. Seeing as maintaining the instances up-to-date is a responsibility of the users, that means that the security of an insecure connection to Cloud SQL also depends on the security of your instances.
Why exactly are you doing insecure connections? I ask because it's incredibly easy to setup a safe connection from an instance to Cloud SQL by using Cloud SQL Proxy! Not to toot my own horn here, but take a look at
this answer I gave a while ago about why you should be using the Proxy.
Regardless, and keeping in mind that Cloud SQL is nothing more than a managed instance exclusively accessible via its public IP, the traffic should stay within GCP in all three of those scenarios, meaning the only thing that is likely to be compromised are the instances in the same sub-network as that of the instance that's connecting to Cloud SQL.
I'm trying to establish a basic mysql connection from a google compute engine instance in one project to a google cloud sql instance (2nd generation) in a different project.
I've done this many times before without any problem. You simply add the ip address of the google compute instance to the list of authorized networks for the google cloud sql instance. This has always worked in the past but it is not working now.
The only thing that I can think of which is different about this situation is that I've recently been experimenting with using the cloudsql-proxy to establish a connection from a different gce instance to the same google cloud sql instance. Could this be the problem? Perhaps the google cloud sql instance is getting confused by having to support both connection mechanisms?
I just need the connection to work. Is there a work-around?
There isn't a problem using both modes of connectivity simultaneously.
The only thing I can think of is that you are accidentally using an ephemeral IP addresses for your VMs instead of static, which means the VM may have a different IP address than you expect (after a restart, for example).
If that's not the case, please send a mail to cloud-sql#google.com with a little bit more information (project and database name, project/name/ip of your VM) so that we can figure out what's going on in the backend.
I have deployed my web server which requires a MySQL database for storage. I've created a Second Generation MySQL instance with one failover replica but I am not sure how I can connect to those.
I am not sure how to configure these instances and what I have to consider here e.g. region/zone. Flexible Environment appears to be unavailable in Europe unfortunately - at the moment at least - so I guess I'll have to place the SQL instances in the US too.
Will those instances have to be in the same local network or can they communicate over regions? Will I even be able to control this or will all this be decided by Google Cloud?
Could anybody who has done this before give me a few details about what to do here?
For best performance, you should place your App Engine instances in the same region.
For information on how to connect from your application to the Cloud SQL MySQL instance see the following documentation: https://cloud.google.com/sql/docs/dev-access#gaev2-csqlv2
The short summary is that you have to modify your app.yaml file to list the Cloud SQL instances you will be connecting to. Once that's done, a local socket will appear inside the App Engine VM that will allow you to connect to your Cloud SQL instance.