Cloud SQL Proxy Operator is an open-source Kubernetes operator that automates most of the intricate steps needed to connect a workload in a kubernetes cluster to Cloud SQL databases.

The operator introduces a custom resource AuthProxyWorkload, which specifies the Cloud SQL Auth Proxy configuration for a workload. The operator reads this resource and adds a properly configured Cloud SQL Auth Proxy container to the matching workload pods.

Check for the latest version on the releases page and use the following instructions.

Confirm that kubectl can connect to your kubernetes cluster.

kubectl cluster-info

Install cert-manager using helm. Note that you need to use this particular version with these specific cli arguments to make cert-manager work on your GKE cluster.

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version "v1.9.1" \
  --create-namespace \
  --set global.leaderElection.namespace=cert-manager \
  --set installCRDs=true

Run the following command to install the cloud sql proxy operator into your kubernetes cluster:

kubectl apply -f https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy-operator/v1.6.0/cloud-sql-proxy-operator.yaml

Confirm that the operator is installed and running by listing its pods:

kubectl get pods -n cloud-sql-proxy-operator-system

See the Quick Start Guide for a description of basic usage. Additional usage may be found in the Examples.

The Cloud SQL Auth Proxy Operator gives you an easy way to add a proxy container to your kubernetes workloads, configured correctly for production use.

Writing the kubernetes configuration for a proxy to the production level requires a great deal of deep kubernetes and proxy knowledge. The Cloud SQL Proxy team has worked to encapsulate that knowledge in this operator. This saves you from having to know all the details to configure your proxy.

• Quick Start Guide
• API Documentation
• Cloud SQL Proxy
• Developer Getting Started
• Developing End-to-End tests
• Contributing
• Code of Conduct
• Examples

This project uses semantic versioning, and uses the following lifecycle regarding support for a major version:

Active - Active versions get all new features and security fixes (that wouldn’t otherwise introduce a breaking change). New major versions are guaranteed to be "active" for a minimum of 1 year. Deprecated - Deprecated versions continue to receive security and critical bug fixes, but do not receive new features. Deprecated versions will be publicly supported for 1 year. Unsupported - Any major version that has been deprecated for >=1 year is considered publicly unsupported.

Contributions are welcome. Please, see the Contributing document for details.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms. See Contributor Code of Conduct for more information.