PostgreSQL pg_hba.conf: Fix 'no pg_hba.conf entry' blocking CI/CD pipeline connections
Quick Fix Summary
TL;DRAdd a matching entry for the CI/CD host's IP and user to pg_hba.conf, then reload PostgreSQL.
The pg_hba.conf file controls client authentication. This error occurs when a connection attempt (from your CI/CD pipeline) doesn't match any rule, causing PostgreSQL to reject it outright.
Diagnosis & Causes
Recovery Steps
Step 1: Verify the Connection Details and Locate pg_hba.conf
First, confirm the exact connection parameters used by the CI/CD pipeline and find the active pg_hba.conf file.
# Get the pipeline's connection host/IP, port, and user.
# Find the pg_hba.conf location:
sudo -u postgres psql -c 'SHOW hba_file;'
# For systemd:
sudo systemctl status postgresql* --no-pager | grep -A5 -B5 'pg_hba.conf'
# Common paths: /var/lib/pgsql/data/pg_hba.conf, /etc/postgresql/*/main/pg_hba.confStep 2: Analyze the Current pg_hba.conf Rules
Examine the existing rules to understand why the pipeline's connection is being rejected.
sudo cat $(sudo -u postgres psql -t -c 'SHOW hba_file;')Step 3: Add an Entry for the CI/CD Pipeline Host
Add a rule that matches the pipeline's source IP/CIDR, database, user, and uses a secure auth method (prefer md5 or scram-sha-256).
# Backup the original file first.
sudo cp $(sudo -u postgres psql -t -c 'SHOW hba_file;') $(sudo -u postgres psql -t -c 'SHOW hba_file;').backup_$(date +%s)
# Append a new rule. Replace <CIDR>, <USER>, <DATABASE>. Example:
echo 'hostssl <DATABASE> <USER> <CIDR> md5' | sudo tee -a $(sudo -u postgres psql -t -c 'SHOW hba_file;') > /dev/null
# Example for a specific IP: 'hostssl all cicd_user 10.10.1.5/32 scram-sha-256'
# Example for a VPC CIDR: 'host all app_user 10.0.0.0/16 md5'Step 4: Reload PostgreSQL Configuration
Apply the changes without a full database restart.
# For systemd:
sudo systemctl reload postgresql
# Alternative using psql:
sudo -u postgres psql -c 'SELECT pg_reload_conf();'Step 5: Test the Connection from a Pipeline-like Context
Simulate the pipeline connection to verify the fix.
PGPASSWORD='your_password' psql -h <POSTGRES_HOST> -p <PORT> -U <CI_USER> -d <DATABASE> -c 'SELECT 1;'Step 6: (Cloud/Managed DB) Check Security Group / Firewall Rules
For AWS RDS, Google Cloud SQL, or Azure DB for PostgreSQL, ensure the pipeline's IP is allowed in the cloud network firewall.
# AWS CLI example to authorize an IP in an RDS security group (VPC). Find your SG ID first.
aws ec2 authorize-security-group-ingress --group-id sg-xxxxxx --protocol tcp --port 5432 --cidr <CI_IP>/32
# For Azure: Use `az postgres server firewall-rule create`Step 7: (Kubernetes) Check Network Policies and Service Configuration
If PostgreSQL runs in Kubernetes, ensure Network Policies allow traffic from CI/CD namespaces/runners and the Service is correctly exposed.
# Check network policies affecting the PostgreSQL pod.
kubectl get networkpolicy -n <postgres-namespace>
# Check the service type and selectors.
kubectl describe svc <postgres-service> -n <postgres-namespace>Architect's Pro Tip
"This often happens when a CI/CD pipeline migrates to dynamic runners (e.g., GitHub-hosted, GitLab SaaS). The IP pool is vast. Instead of whitelisting, use a secure authentication proxy (like Cloud SQL Auth Proxy) or a VPN to present a fixed, trusted source IP to the database."
Frequently Asked Questions
I added the rule and reloaded, but the error persists. What's wrong?
The connection parameters (host, port, user, database, SSL mode) must match the rule *exactly*. Double-check for typos, CIDR format, and that you're editing the *correct* pg_hba.conf file (use `SHOW hba_file;`). Also, ensure no earlier 'reject' or 'all' rule is matching first, as rules are processed top-down.
Is using 'trust' authentication for my CI/CD pipeline safe?
No. Never use 'trust' for remote connections, especially from internet-accessible CI runners. It allows password-less access. Always use 'md5' or preferably 'scram-sha-256' and manage passwords/secrets securely in your CI/CD system's vault.
How do I handle this for a large, changing pool of CI runner IPs?
Avoid IP-based whitelisting. Implement a secure authentication layer: 1) Use a cloud database's IAM authentication (e.g., AWS RDS IAM), 2) Deploy a connection proxy/bastion with a fixed IP that runners connect through, or 3) Establish a site-to-site VPN between your CI network and database VPC.