Container Escape in Rails with Cockroachdb

A container escape in a Ruby on Rails application using CockroachDB occurs when a process inside a container gains the ability to interact with the host system or other containers in unintended ways. This specific combination can amplify risks because Rails applications often rely on persistent database connections and configuration that, if improperly isolated, may be leveraged to escape the container boundary.

Rails applications typically connect to CockroachDB via connection strings that include hostnames or IPs. If these values are derived from environment variables injected at runtime without strict validation, an attacker might manipulate them to point to services outside the intended network namespace. For example, a misconfigured DATABASE_URL could direct traffic to a host-mapped IP such as host.docker.internal, enabling interaction with processes on the host or adjacent containers.

Another vector involves volume mounts. Rails applications often mount directories for logs, temporary files, or configuration. If a container runs with elevated privileges and CockroachDB credentials are stored in these volumes, an attacker who achieves code execution within the container could read or modify those credentials, potentially accessing the database cluster outside the container’s security context.

Additionally, CockroachDB’s SQL interface may expose system tables or diagnostic endpoints. If Rails applications use raw SQL queries that incorporate user input without proper sanitization, this could facilitate command execution or data exfiltration that extends beyond the application layer into the container runtime.

In a containerized deployment, network policies play a critical role. Without restrictive policies, a compromised Rails container might be able to reach CockroachDB instances on non-standard ports or even other services that share the same overlay network, increasing the blast radius of a container escape.

To mitigate container escape risks when using CockroachDB with Rails, implement strict input validation, environment isolation, and secure connection practices.

1. Validate and restrict database host configuration

Ensure the database host is explicitly defined and not derived from user-controlled sources. Use a fixed hostname that resolves only within the intended network segment.

# config/database.yml
production:
  url: <%= ENV.fetch("DATABASE_URL") { "postgresql://user:password@cockroachdb-internal:26257/mydb?sslmode=require" } %>

Avoid using host.docker.internal or dynamic host resolution unless absolutely necessary and properly constrained.

2. Use Kubernetes network policies to isolate pods

Define a NetworkPolicy that limits ingress and egress traffic for your Rails pod. This prevents the container from reaching unexpected services, including other containers or the host network.

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: rails-cockroachdb-policy
spec:
  podSelector:
    matchLabels:
      app: rails
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: cockroachdb
    ports:
    - protocol: TCP
      port: 26257
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: cockroachdb
    ports:
    - protocol: TCP
      port: 26257

3. Secure credential storage and usage

Store CockroachDB credentials in Kubernetes Secrets and reference them as environment variables. Avoid embedding credentials in code or volume mounts that are writable by application processes.

# rails app code
require 'pg'

conn = PG.connect(
  host: ENV['COCKROACHDB_HOST'],
  port: ENV.fetch('COCKROACHDB_PORT', 26257),
  dbname: ENV['COCKROACHDB_DATABASE'],
  user: ENV['COCKROACHDB_USER'],
  password: ENV['COCKROACHDB_PASSWORD'],
  sslmode: 'require'
)

4. Parameterize queries to prevent SQL injection

Even when using an ORM like ActiveRecord, ensure that raw SQL fragments are parameterized. This prevents attackers from injecting commands that could reach beyond the application layer.

# app/models/user.rb
class User < ApplicationRecord
  scope :search_by_name, ->(name) {
    where("name = $1", name)
  }
end

# Usage
User.search_by_name(params[:name]).to_a

5. Limit container privileges

Run the Rails container as a non-root user and disable unnecessary capabilities. This reduces the impact of a potential container escape through the Rails or CockroachDB process.

# Dockerfile
FROM ruby:3.2
RUN useradd -m railsuser
USER railsuser
WORKDIR /app