Enable Developer Hub with Cloud SQL and Workload Identity Federation in GKE

In this lesson, we’ll walk through enabling Developer Hub with Cloud SQL using Workload Identity Federation. This setup ensures secure and efficient database connectivity by leveraging Google Cloud’s managed services and robust security mechanisms. Connecting to Cloud SQL from within GKE requires the use of a sidecar which provides secure connectivity and  authentication. This configuration also briefly explores customizing database configuration for Developer Hub.

In this lesson, you will:

• Enable Developer Hub with Cloud SQL using Workload Identity Federation.

Overview

The goal of this lesson is to leverage Workload Identity Federation for seamless authentication between your Kubernetes workload and the Cloud SQL. Workload Identity Federation eliminates the need to manage service account keys by mapping Kubernetes service accounts (KSAs) to Google Cloud service accounts (GSAs).

This process uses a GSA with necessary permissions for the Cloud SQL and maps it to the Kubernetes workload through Workload Identity Federation.

Step-by-step guide

1. This step ensures the application relies on the external Cloud SQL instance instead of an internal database. To update the Helm configuration, disable the upstream Postgres service in your values.yaml file:

   upstream: 
     postgres: 
       enabled: false

2. Ensure that the Cloud SQL Admin API is enabled for your project. You can enable it as described here: Enable Cloud SQL Admin API.

3. Run the following command to create a Cloud SQL Postgres instance and a database user:

   gcloud sql instances create INSTANCE_NAME \ --database-version=POSTGRES_15 \ --cpu=2 \ --memory=4GB \ --region=australia-southeast2 \ --network=NETWORK_NAME \ --no-assign-ip
   
   gcloud sql users create USERNAME \ --instance=INSTANCE_NAME \ --password=PASSWORD

4. Assign IAM roles for the GSA by granting the GSA the required cloudsql.client role to enable access to the Cloud SQL instance:

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member "serviceAccount:${GSA}@${PROJECT_ID}.iam.gserviceaccount.com" \ --role "roles/cloudsql.client"

5. Granting database permissions is optional. If using a Cloud IAM user to connect to the database, provide the appropriate permissions on the Cloud SQL instance for the GSA. If using a standard database user, this is not required, and it has default permissions to create Developer Hub databases.

   Cloud SQL provides a utility called Cloud SQL Proxy which provides the following features:

   • Secure connections:
     • The proxy establishes a secure SSL/TLS connection between your application and the Cloud SQL database.
     • Data is encrypted in transit, ensuring protection against interception.
   • IAM integration:
     • Instead of hardcoding credentials, the proxy uses IAM roles and permissions to authenticate your application.
     • It ensures that only authorized entities can access the database.
   • Local and remote compatibility:
     • Works in both local development environments and production environments on GCP (e.g., Compute Engine, Kubernetes, Cloud Run, App Engine).
   • Simplifies configuration:
     • Manages ephemeral IP addresses and connections automatically.

     • Eliminates the need to manually whitelist IPs or configure SSL certificates for your application.

       Cloud SQL Proxy can be run as a sidecar alongside a Developer Hub container. The application connects to it as if it is the database endpoint, and the Cloud SQL Proxy handles connecting to the actual Cloud SQL instance.

6. Add a sidecar container in your deployment to facilitate communication with the Cloud SQL instance by adding the following configuration in your values.yaml under upstream.backstage:

   extraContainers:
     - name: cloud-sql-proxy
       image: gcr.io/cloud-sql-connectors/cloud-sql-proxy
       args:
         - "--structured-logs"
         - "--port=5432"
         - "<db-instance>"
         - "--private-ip"
       securityContext:
         runAsNonRoot: true
   
   extraEnvVars:
     - name: POSTGRESQL_ADMIN_PASSWORD
       valueFrom:
         secretKeyRef:
           key: postgres-password
           name: rhdh-secret
     - name: BACKEND_SECRET
       valueFrom:
         secretKeyRef:
           key: backend-secret
           name: rhdh-auth        

7. Configure the application to use Cloud SQL by updating the database connection configuration in your values.yaml under upstream.backstage.backend file as follows:

   database:
     client: pg
     connection:
       host: '127.0.0.1'
       port: '5432'
       user: ${DB_USER}
       password: ${DB_PASSWORD}
     prefix: devhub_plugin_

   Use the optional prefix to add a custom prefix to plug-in database instances created by Developer Hub.

   Create a secret for DB_USER credentials:

   kind: Secret
   apiVersion: v1
   metadata:
     name: rhdh-secret
     namespace: rhdh-gke
   stringData:
     DB_USER: <username>
     postgres-password: <pwd>
     DB_PASSWORD: <pwd>
   type: Opaque

8. Update the deployment:

   helm upgrade rhdh \
       openshift-helm-charts/redhat-developer-hub \
       --namespace rhdh-gke \
       --values values-cloudsql.yaml

Key takeaways

This learning path has demonstrated the following:

• Using Cloud SQL with Workload Identity Federation offers secure database connectivity.
• Adding a sidecar container simplifies access to the Cloud SQL instance by abstracting the connectivity details.

By following this guide, your RHDH deployment will leverage the scalability and reliability of Google Cloud SQL while adhering to cloud security and architecture best practices. 

Ready to learn more about Red Hat Developer Hub? Explore these offerings:

• E-book: Developer Portals: Prepare to Perform with Red Hat Developer Hub
• Learning path: Install and configure Red Hat Developer Hub and explore templating basics
• Article: Red Hat Developer Hub: Your gateway to seamless development
• Video: Introduction to Red Hat Developer Hub for developers and platform engineers