Fouad Matin

@fouadmatin

Dan Gillespie

@ethernetdan

When it comes to production databases, balancing access and security is key. Occasionally, we need to grant short-term database access for debugging a recent deploy or resolving a customer issue.

Yet, unchecked access is a security risk. This post will detail how to start granting temporary database access to Google Cloud SQL.

Granting access to your database on Google Cloud isn't a casual decision. While it might seem easier to give indefinite access, there are compelling reasons to opt for temporary permissions:

1. Security: The longer someone has access, the larger the window of opportunity for potential misuse, whether intentional or accidental. Temporary access minimizes this risk.
2. Principle of Least Privilege (PoLP): This security concept advises giving users only the permissions they absolutely need, and only for as long as they need them. It reduces the potential damage of security breaches.
3. Audit and Compliance: With temporary access, it's easier to track who accessed what and when. This is crucial for regulatory compliances and internal audits.
4. Resource Efficiency: Permanent access might mean more active connections, more licenses, or more potential resource drain. Temporary access helps manage resources more judiciously.
5. Management Overhead: Continuously monitoring users with permanent access can be taxing. Temporary permissions streamline user management, as they expire automatically.

In essence, temporary database access isn't just a best practice or something to do for compliance—it's a necessity in maintaining a secure and efficient Google Cloud environment.

Before, we get into how to set up temporary access, let's look at the different ways of accessing Google Cloud SQL databases.

In order to get access to a Google Cloud SQL, there has to be a database user and a network connection to the database.

The database user is the account that is used to connect to the database. The network connection is the path that the human user takes to connect to the database.

When rendered, this table will neatly present the information for each access method alongside the team size it's most suitable for. Adjustments can be made based on specific organizational nuances and preferences.

1. Direct Connect: DB User Per Human User

This approach is the most straightforward, but can be cumbersome to manage as your team grows. When a user joins, they get a unique user name and will need to be added to the instance:

gcloud sql users create $USER_NAME \
  --instance=$INSTANCE_NAME \
  --password=$PASSWORD

Then you will need to grant database privileges on that user:

grant select on "$TABLE_NAME" to "$USER_NAME";

• How it works
  • Each engineer gets a unique database user account, allowing direct connection to the database.
  • Users can be added or removed as needed, can be granted specific permissions, and can be assigned a unique password. They can use MySQL tools or PostgreSQL tools to connect to the database.
• Pros
  • Audit Trail: With individual accounts, it's easier to monitor who did what and when for compliance and auditing purposes.
  • Fine-grained Access Control: User-level permissions can be tuned to each engineer's needs, down to the table or column level.
• Cons
  • Management Overhead: Handling credentials, permissions, and on/off-boarding can become complex as your team grows.
  • Integration Complexity: Initial setup might require a bit more effort, especially in hybrid or multi-cloud environments.

2. Bastion Host/Jumpbox with VPN

Think of this as a fortified gateway to your database. On this server (or container), you can record and monitor all database activity, and run a VPN to ensure secure connections.

Users can be managed directly from the networking layer and role-based access to the database through the monitored gateway.

Teams will often distinguish between read-only and read-write access, and set up isolated database users and gateways for each.

• db-read would grant access to read-only like SELECT
• db-write would grant access to INSERT, UPDATE, and DELETE
• db-admin would grant full admin access like GRANT or DROP

Here are some examples of VPN solutions:

• Tailscale
• Twingate
• HashiCorp Boundary
• Google Cloud Identity-Aware Proxy (IAP)

Once the users and gateways are set up, users can either SSH or connect directly via the networking solution to the database.

• How it works
  • Engineers first connect to a bastion host or jumpbox, which is a secured, intermediate server. From there, they access the database.
  • Logs from the server can stream into your SIEM or log management tool for auditing and compliance. We recommend setting up alerts for unexpected behaviors like SELECT without LIMIT or any kind of destructive actions.
• Pros
  • Secure Network: The database isn't directly exposed to the open internet, but still easy for authorized users to access.
  • Centralized Management: All traffic funnels through a single, managed point, simplifying monitoring and security protocols.
• Cons
  • Single Point of Failure: If the bastion host faces issues, access to all databases can get hampered. This can be solved with redundant bastion servers, but that adds to cost.
  • Increased Latency: Adding an intermediary can add a minor delay to connections or if too many users are querying, slow down the database.

3. Identity-Aware Database Proxy

Once your team grows to the point that managing individual database users is not feasible and role-based VPN-driven access doesn't have enough granularity of control, there are identity-aware proxy solutions designed for databases.

You can use your identity provider Okta, Microsoft Azure AD/Entra ID or Google Workspace as the identity provider and manage role-based access through identity groups.

Here are some database proxy solutions:

• Teleport
• StrongDM

These solutions are designed to integrate directly with your database and provide a single point of entry for all users. They can be configured to provide granular access control, and can be integrated with your identity provider for seamless onboarding and offboarding.

• How it works
  • Connect your database to the proxy solution, and configure it to integrate with your identity provider.
  • Monitor and record individual user sessions in real-time, ensuring admins know who is accessing what and when.
• Pros
  • Granular Oversight: Real-time monitoring means unexpected behaviors or breaches can be spotted and rectified swiftly.
  • Streamlined Access: These solutions often provide a single point of entry for multiple databases or resources, simplifying the process for engineers.
• Cons
  • Integration Complexity: Initial setup might require a bit more effort, especially in hybrid or multi-cloud environments.
  • Cost: Advanced solutions come with a price tag. However, the security benefits often outweigh the monetary costs.

Based on your organization's size, security requirements, and operational preferences, any of these solutions could be the right fit.

Once you've picked the preferred access pattern, you can start shifting users to temporary access in order to minimize risk and implement the principle of least privilege.

Indent is an access management platform that integrates with a myriad of services to allow on-demand access requests. It lets admins configure policies, and users can request temporary permissions which, upon approval, are provisioned automatically.

This can be a game-changer for organizations aiming to manage temporary database access dynamically and securely.

Here's how you can use Indent for each of the access patterns we discussed earlier:

1. Direct Connect: DB User Per Human User
   • Setup
     • Define access policies for specific roles or access levels in the database.
     • Create a your Google Cloud Function with elevated access to your database and set up as a webhook with Indent.
   • Workflow
     • An engineer requests access by typing /access in Slack or indent.com/access on the web.
     • Upon approval (either manual or automated, depending on your configuration), Indent provisions a temporary user in the database with the specified permissions.
     • Once the access duration expires, Indent revokes the user's permissions or deletes the temporary user altogether.
2. Bastion Host/Jumpbox with VPN
   • Setup
     • Set up Indent with your networking provider like Tailscale to manage temporary role-based access via groups.
     • Configure policies dictating who can access the bastion host and under which conditions. For example, you can set up a policy that auto-approves access for on-call engineers.
   • Workflow
     • Engineers request access to the bastion host via Indent.
     • Upon approval, Indent grants temporary SSH access to the bastion host.
     • Engineers can then use this access to connect to the database, often using their personal credentials or temporary tokens.
     • Access to the bastion host is revoked by Indent after the stipulated time.
3. Identity-Aware Database Proxy
   • Setup
     • Set up Indent with your identity provider that's connected to the proxy.
     • Use Indent to move users in and out of identity groups to grant access.
   • Workflow
     • When engineers need access, they put in a request via Indent.
     • Once approved, Indent adds the user to a group in the identity provider that grants the engineer temporary access to the requested database.
     • All sessions are monitored, and Indent ensures access is revoked after the agreed-upon duration.

Indent can help reduce the amount of standing production access to meaningfully improve security, without adding a ton of friction for engineers who need access urgently.

For some companies, it can resolve compliance requirements for certifications like SOC 2 Type II, ISO 27001, PCI DSS, or SOX.

We're happy to help you think through the right access patterns for your team and use case, feel free to reach out for a demo or contact us.

If you want to hear from a customer's experience with setting up Google Cloud SQL with Tailscale and Indent, check out this post from Stevan Arychuk (Head of SRE at Reclaim.ai) on the Tailscale blog.