From 40605e52e630bf55fc72ed93a4da0281da660f12 Mon Sep 17 00:00:00 2001 From: Dave Gallant Date: Wed, 31 May 2023 22:39:12 -0400 Subject: [PATCH] Add some additional context to aks post --- ...ing-aks-and-socks-to-connect-to-a-private-azure-db.md | 9 +++++---- .../index.html | 9 +++++---- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/content/post/using-aks-and-socks-to-connect-to-a-private-azure-db.md b/content/post/using-aks-and-socks-to-connect-to-a-private-azure-db.md index 058f52d2..e083afe1 100644 --- a/content/post/using-aks-and-socks-to-connect-to-a-private-azure-db.md +++ b/content/post/using-aks-and-socks-to-connect-to-a-private-azure-db.md @@ -36,11 +36,11 @@ sequenceDiagrams: ## The Problem -I ran into a roadblock recently where I wanted to be able to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I'd rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection. After several web searches, it became evident that Azure does not readily provide much tooling to support this. +I ran into a roadblock recently where I wanted to be able to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I'd rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection, and I'd like to use a local client (preferably with a GUI). After several web searches, it became evident that Azure does not readily provide much tooling to support this. ## Go Public? -Should the database be migrated to public subnets? Ideally not, since it is good practice to host critical infrastructure in restricted subnets. +Should the database be migrated to public subnets? Ideally not, since it is good practice to host internal infrastructure in restricted subnets. ## How do others handle this? @@ -52,9 +52,10 @@ So what about Azure? Is there any solution that is as elegant as cloud-sql-proxy Similar to what [AWS has recommended](https://aws.amazon.com/blogs/database/securely-connect-to-an-amazon-rds-or-amazon-ec2-database-instance-remotely-with-your-preferred-gui/), perhaps a bastion is the way forward? -[Azure Bastion](https://azure.microsoft.com/en-ca/products/azure-bastion) is a fully managed service that both [costs money](https://azure.microsoft.com/en-ca/pricing/details/azure-bastion/#pricing) and provides secure access to virtual machines that do not have public IPs. +Azure has a fully-managed service called +[Azure Bastion](https://azure.microsoft.com/en-ca/products/azure-bastion) that provides secure access to virtual machines that do not have public IPs. This looks interesting, but unfortunately it [costs money](https://azure.microsoft.com/en-ca/pricing/details/azure-bastion/#pricing) and requires an additional virtual machine. -Because this adds cost and requires a virtual machine, it does not seem like a very desirable option in its current state. +Because this adds cost (and complexity), it does not seem like a desirable option in its current state. If it provided a more seamless connection to the database, it would be more appealing. ## SOCKS diff --git a/public/blog/2023/05/22/using-aks-and-socks-to-connect-to-a-private-azure-db/index.html b/public/blog/2023/05/22/using-aks-and-socks-to-connect-to-a-private-azure-db/index.html index 9070ef57..b05f851f 100644 --- a/public/blog/2023/05/22/using-aks-and-socks-to-connect-to-a-private-azure-db/index.html +++ b/public/blog/2023/05/22/using-aks-and-socks-to-connect-to-a-private-azure-db/index.html @@ -103,16 +103,17 @@

The Problem#

-

I ran into a roadblock recently where I wanted to be able to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I’d rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection. After several web searches, it became evident that Azure does not readily provide much tooling to support this.

+

I ran into a roadblock recently where I wanted to be able to conveniently connect to a managed postgres database within Azure that was not running on public subnets. And by conveniently, I mean that I’d rather not have to spin up an ephemeral virtual machine running in the same network and proxy the connection, and I’d like to use a local client (preferably with a GUI). After several web searches, it became evident that Azure does not readily provide much tooling to support this.

Go Public?#

-

Should the database be migrated to public subnets? Ideally not, since it is good practice to host critical infrastructure in restricted subnets.

+

Should the database be migrated to public subnets? Ideally not, since it is good practice to host internal infrastructure in restricted subnets.

How do others handle this?#

With GCP, connecting to a private db instance from any machine can be achieved with cloud-sql-proxy. This works by proxying requests from your machine to the SQL database instance in the cloud, while the authentication is handled by GCP’s IAM.

So what about Azure? Is there any solution that is as elegant as cloud-sql-proxy?

A Bastion#

Similar to what AWS has recommended, perhaps a bastion is the way forward?

-

Azure Bastion is a fully managed service that both costs money and provides secure access to virtual machines that do not have public IPs.

-

Because this adds cost and requires a virtual machine, it does not seem like a very desirable option in its current state.

+

Azure has a fully-managed service called +Azure Bastion that provides secure access to virtual machines that do not have public IPs. This looks interesting, but unfortunately it costs money and requires an additional virtual machine.

+

Because this adds cost (and complexity), it does not seem like a desirable option in its current state. If it provided a more seamless connection to the database, it would be more appealing.

SOCKS#

SOCKS is a way to proxy connections by exchanging network packets between the client and the server. There are many implementations and many readily available container images that can run a SOCKS server.

It is certainly possible to use this sort of proxy to connect to a private DB, but is it any simpler than using a virtual machine as a jumphost? It wasn’t until I stumbled upon kubectl-plugin-socks5-proxy that I was convinced that using SOCKS could be made simple.