# Acessando suas instâncias Cloud SQL com  SQL Auth Proxy

Esse serviço oferece um meio seguro de acessar suas instâncias do Cloud SQL sem precisar de [redes autorizadas](https://cloud.google.com/sql/docs/postgres/configure-ip) ou mesmo [configurar SSL](https://cloud.google.com/sql/docs/postgres/configure-ssl-instance) para fazer conexão ao banco de dados. Ele oferece algumas vantagens:

- **Conexões seguras**: o Auth Proxy automaticamente encripta todo o tráfego de dados de ponta a ponta utilizando TLS 1.3 com 256-bit _AES cipher_. Em toda a comunicação é utilizado certificados SSL para verificar a identidade do _client_ e do _server_, independente do protocolo do banco de dados, fora que não precisa gerenciá-los.
- **Autorização de conexão facilitada**: é utilizado as permissões _IAM_ para controlar quem e quando conectar na sua instância. Além disso o Auth Proxy lida com a autenticação com o Cloud SQL, de forma que remove a necessidade  de prover um endereço de IP estático.
- **Autenticação do banco via IAM**: opcionalmente o Auth Proxy suporta a opção de atualização automática de tokens _OAuth 2.0_

O Auth Proxy não fornece um novo caminho de conectividade, então ele depende da conectividade existente. Para conectar utilizando o IP privado, é preciso estar em um recurso com acesso à mesma rede VPC da instância.


## Requisitos de utilização

Para fazer uso dela precisa seguir algumas premissas:

- Precisa ter o _Cloud SQL Admin API_ habilitado
- Prover para o Auth Proxy credenciais de autenticação do GCP
- Prover para o Auth Proxy as contas de usuário e senhas do banco válidos
- A instância deve ter um IP público IPv4 ou ser configurado para utilizar o IP privado

Para fazer a instalação, [siga as instruções da documentação](https://cloud.google.com/sql/docs/postgres/sql-proxy#install).


## Como o Cloud SQL Auth Proxy funciona?

O serviço segue alguns passos para chegar no objetivo que é disponibilizar uma conexão disponível no banco:

1. Começando por um _client_ local executando no mesmo ambiente da aplicação, por exemplo. Ela comunica com o Auth Proxy através do protocolo do banco de dados, como seria comunicado diretamente com a base de dados.
2. Em seguida, o Auth Proxy usa um túnel seguro para comunicar com o processo semelhante sendo executado no servidor. Cada conexão estabelecida através do Auth Proxy cria uma conexão para a instância Cloud SQL.
3. Quando essa aplicação conecta através do Auth Proxy, o _client_ local verifica se já possui uma conexão disponível entre ela, e a instância Cloud SQL. Caso contrário, é solicitado uma nova, gerando inclusive certificados SSL efêmeros e assim utilizados nessa comunicação

Abaixo a imagem traz uma visão geral de tudo isso:

![Pasted image 20220322125514.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1663707184387/wkFiFdM8Q.png align="left")

> **Observação:** Esse certificados efêmeros expiram em aproximadamente 1 hora, mas o Auth Proxy tem a inteligência de solicitar uma renovação antes disso acontecer.


## Autenticação via Service Account

O Cloud SQL Auth Proxy se utiliza dos Service Accounts para autorizar a conexão entre o _client_ e a instância. Dessa forma, tenha disponível essa chave e passe via parâmetro para o `cloud_sql_proxy`. Quando for utilizar esse meio, se certifique que sua chave tenha a _role_ que gerencia as ações necessárias no Cloud SQL, portanto, dentre sua lista de permissões adicione `cloudsql.instance.connect` entre elas para que tenha disponível ações relacionados a:

- Cloud SQL Client
- Cloud SQL Editor
- Cloud SQL Admin


## Criando conexão para acesso ao banco de dados

Abaixo temos um exemplo de execução do comando `cloud_sql_proxy` para criar uma nova conexão com uma instância, a partir do seu _Connection Name_, que é o mais recomendado porque ele atua como um “DNS” do recurso, sem recorrer a IP estáticos:

```bash
cloud_sql_proxy -instance=projecttest-1235:us-central1:my-cloudsql-instance=tcp:5432
```

Com o comando acima é disponibilizado um acesso a instância a partir do protocolo TCP, utilizando o host _localhost_ e a porta _5432_. Quando é executado esse comando, aparece algumas informações interessantes que traz relação ao que falamos anteriormente:

```
2022/03/22 14:56:54 Rlimits for file descriptors set to {Current = 8500, Max = 524288}
2022/03/22 14:56:55 Listening on 127.0.0.1:5432 for projecttest-1235:us-central1:my-cloudsql-instance
2022/03/22 14:56:55 Ready for new connections
2022/03/22 14:56:55 Generated RSA key in 86.817487ms
```

Isso significa que a instância está disponível. Agora se tentarmos uma conexão ao banco de dados, utilizando o cliente da mesma ferramenta, que no nosso caso seria o `psql`, e passasse os dados necessários como o nome do banco, host, porta e credenciais, ele vai gerar o certificado efêmero e finalizar a comunicação para finalmente acessar a base:

```bash
psql -U postgres -h 0.0.0.0 -p 5432 -d my-database
```

```
2022/03/22 14:57:06 New connection for "projecttest-1235:us-central1:my-cloudsql-instance"
2022/03/22 14:57:06 refreshing ephemeral certificate for instance projecttest-1235:us-central1:my-cloudsql-instance
2022/03/22 14:57:07 Scheduling refresh of ephemeral certificate in 54m59.591751748s
```