I was thinking not to set any External IP Addresses on the cockroach database cluster that I will be launching, as I would be connecting to the cluster using the Internal IP Addresses itself.
I am deploying the cluster on GCP (Google Cloud Platform) and would have other application servers that would have External IPs and would interface with the Database Cluster.
I wanted to know, if there are any drawbacks or generally not a good practice to proceed with the above configuration.
In my opinion it is a good decision to avoid external IPs as much as possible, especially for databases and backend servers. it is an increase in security on the expense of convince in connecting (e.g. direct SSH).
You'll be able to SSH to such servers as needed by opening SSH tunnels from other VMs in the same VPC or VPN (openvpn, tinc, ..).
Related
We have a website up and running, and we decided to move to Azure.
The database was migrated to SQL Azure using the DMA (Data Migration Assistant), and we created a VM on Azure, then we published the website on IIS on the VM.
Now, we have two different domains with two different databases, and the old website is much faster than the new one (azure website).
We couldn't find exactly where is the bottleneck; in the database, or in the connection, or in the VM (processor or IIS, ...).
The specifications of the Azure resources:
VM: Standard D2s v3 (2 vcpus, 8 GB memory)
DB: Premium P1: 125 DTUs
Can anyone hint us how to detect the main cause of this slowness?
If your application have load then the best practice to do that host your application on a different azure machine and host your database on a different azure server and make a virtual network between your machines.
When you create an Azure virtual machine (VM), you must create a
virtual network (VNet) or use an existing VNet. You also need to
decide how your VMs are intended to be accessed on the VNet. It is
important to plan before creating resources and make sure that you
understand the limits of networking resources.
Load balancers
Azure Load Balancer delivers high availability and
network performance to your applications. A load balancer can be
configured to balance incoming Internet traffic to VMs or balance
traffic between VMs in a VNet. A load balancer can also balance
traffic between on-premises computers and VMs in a cross-premises
network, or forward external traffic to a specific VM.
The load balancer maps incoming and outgoing traffic between the
public IP address and port on the load balancer and the private IP
address and port of the VM.
Read this to configure.
I was moving all website to google cloud and encounter a performance problem.
I set up a VM instance on Compute Engine and a Cloud SQL server.
And connect the Joomla website from VM to Cloud SQL server using provided IP address. (Seems public IP)
The performance is really slow compared to the website using local database inside the VM itself.
So, my question is, is there a way to find local IP to connect to Cloud SQL since our web server is also on the Google Cloud infra itself.
Or, the only way is to stick with the database inside VM?
Update
I set up the Cloud proxy using this guide.
Can connect to mysql prompt with the proxy now.
But still cannot find a way to let joomla use this cloud proxy to connect to the database.
The fastest, easiest, and most secure way to connect to your Cloud SQL instance from your Compute instance is by using the Cloud SQL Proxy. There are multiple reasons for this, but here are the main ones:
Secure connections: The proxy automatically encrypts traffic to and from the database using TLS 1.2 with a 128-bit AES cipher; SSL certificates are used to verify client and server identities.
Easier connection management: The proxy handles authentication with Google Cloud SQL, removing the need to provide static IP addresses.
There's also the fact that you only need a static and small number of instances (1 in your case) connecting to the database, so you don't really need to overcomplicate your setup, you can just drop this binary into your instance, run it as a daemon, and instantly have a fast lane to your Cloud SQL instance (I use "fast lane" here because the traffic will go through Google Cloud's internal network).
Setting up the Cloud SQL Proxy comes down to enabling the Cloud SQL API, giving the service account of your intance access to the Cloud SQL API, making sure the binary has execution permissions (chmod +x), and giving it the connection string to the Cloud SQL instance. You seem to be having issues using the Proxy, so if you need more troubleshooting ideas, you can find them in the documentation. The tutorial you've followed should have detailed instructions on how to do these steps.
After all of that and after making sure the Proxy is running, connecting Joomla to the database should be similar to how you do it via the MySQL client. You should point your Joomla installation to localhost (or 127.0.0.1), give it a set of credentials to access the database itself (you can create database users via the Console), give your Joomla database's name, and that should be it!
Don't forget that the Proxy needs to be running in TCP mode! That should be as simple as adding =tcp:LOCAL_PORT_TO_LISTEN_ON to the connection string parameter you're passing to the Proxy. Here's an example of how to run the Proxy:
./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306
Virtual Private Cloud (VPC) helps to increase the performance.
Private Google access enables virtual machine (VM) instances on a subnetwork to reach Google APIs and Services using an internal IP address rather than an external IP address. You can use Private Google access to allow VMs without Internet access to reach Google services.
Here you get more details: https://cloud.google.com/vpc/docs/private-google-access
I would like to connect a volttron platform running on a raspberry pi connected to the local network of a building to a second volttron platform running on a virtual personal server.
I know that two volttron platforms can interact with each other using the Volttron Central Management Agent or using the ForwardAgent. However, it is not clear to me what security method is used. Our ICT manager only agrees to set up a connection if the information is exchanged through https.
Could you help me formulating an answer to ICT regarding the security issue? And give me some pratical tips on how to set up the volttron configuration files? I'm not very familiar with network/security technologies. Maybe important to know: the server has a proxy and a reverse-proxy security.
Thx!
Your security person is correct. You should only set the platform up in a "real" environment through https. Since you have a proxy, that should be forwarded to the volttron central agent.
internet (443) -> proxy -> http://127.0.0.1:8080
The proxy in this case is on the same machine as the volttron central platform.
This is how we are doing it with apache as our proxy. One could do the same thing with a different web server such as nginx.
Hopefully that helps
If you are indeed trying to connect from a single instance to another instance (e.g. the way the forwarder does). Then the answer is the security is using public/private key pairs with curve mq providing perfect forward security. All traffic between platforms is 100% encrypted and only authorized agents can transmit across the instances bus.
http://curvezmq.org/
I am trying to secure online transaction between application server and database. One-way is SSL, but is there any other way of securing transaction between them. I am trying to reduce the overhead in securing the line. Are there any tool or api's which I can integrate with the application server or deploy on it.
/SR
Sure, but it requires a thoughtful review of your architecture. If you have a dedicated line between your application and your database, the connection could be encrypted at the network layer.
I'm a bit surprised that your application server and your database are not within the same trust boundary. Is this an app in the cloud?
SSL is by far the best way, its extremely secure and absolutely free. If your database or another application doesn't support SSL then you can use a free SSL VPN such as OpenVPN. This will create a secure transport layer connection between 2 machines.
If you are connecting to a database on the local machine then there is no point in a secure transport layer connection. However you should firewall off the database port, for instance MySQL uses tcp 3306.
I was readin this month edition of SQL Server Magazine and in an article about securing Sql Server environment , the author mentioned that developer should try to have the website and the databases run in separate servers for security. I have a shared hosting account and was wondering if it makes sense to buy a second account to move all databases there. Or does it only make sense when using dedicated servers? How would it affect performances on my website?
I use asp.net and have a hosting account with DisountAsp
That article probably doesn't apply to your situation. Running the database on a separate server is a measure to protect against root compromise of the web server hosting machine. I a shared hosting environment the same situation would result in compromising all accounts on that machine anyway. Depending on the particular settings of your hosting, your account database may alreayd be on a separate server.
Besides, with a shared hosting account is very unlikely you'll even be able to query a database from another account.
If you buy a second server, what will it be, a VPS? I imagine you will get more CPU cycles on a VPS with a dedicated database server than a dedicated machine with multiple databases, but who really knows.
Still, your host isn't running websites on their shared database servers, so what's the difference, security wise?
Performance would me my number one driving factor. I mean if someone compromises your web server, unless your connection strings are encrypted, they've got what they need to connect to the DBs.