使用Volumes部署带SSL证书和密钥的PostgreSQL Docker容器权限问题

Hey there! Great question—this is a super common pain point when setting up PostgreSQL with SSL in containers. The good news is you don’t have to rewrite the Dockerfile if you don’t want to; you can absolutely get this working just with volumes, though there’s also a Dockerfile approach if that fits your workflow better. Let’s break down both options:

Option 1: Fix Permissions Using Only Volumes #

The core issue here is that files mounted from your host retain their host-side permissions, and the postgres user in the official container has a UID of 999 (you can verify this with docker run --rm postgres:latest id postgres). Here are two reliable ways to fix this without touching the Dockerfile:

Sub-option 1a: Adjust Permissions on the Host First #

This is the simplest approach if you have control over the host filesystem:

1. Change the owner of your cert/key files to match the postgres user’s UID in the container:

   sudo chown 999:999 /path/to/your/server.crt /path/to/your/server.key
   

2. Lock down the permissions to 600 (required by PostgreSQL for the private key):

   sudo chmod 600 /path/to/your/server.crt /path/to/your/server.key
   

Now when you mount these files into the container, the postgres user will have full read access, and the permissions will be exactly what PostgreSQL expects.

Sub-option 1b: Adjust Permissions at Container Startup #

If you can’t modify host permissions (e.g., shared filesystem, restricted access), you can run a quick permission fix before starting PostgreSQL. For example, in a docker-compose.yml:

services:
  postgres:
    image: postgres:latest
    volumes:
      - ./ssl:/var/lib/postgresql/ssl
    environment:
      POSTGRES_PASSWORD: your_password
    command: >
      bash -c "chown postgres:postgres /var/lib/postgresql/ssl/* && 
               chmod 600 /var/lib/postgresql/ssl/* && 
               exec postgres"

The exec postgres part is critical—it replaces the bash process with the PostgreSQL server, ensuring proper signal handling (so the container shuts down gracefully, for example).

Option 2: Use a Custom Dockerfile (For Persistent Config) #

If you want a self-contained image that doesn’t require host-side tweaks or startup commands, building a custom image is a solid choice. Here’s a minimal example:

FROM postgres:16

# Create the SSL directory (if it doesn't exist)
RUN mkdir -p /var/lib/postgresql/ssl

# Copy your certs into the container
COPY ./ssl/server.crt /var/lib/postgresql/ssl/
COPY ./ssl/server.key /var/lib/postgresql/ssl/

# Set the correct owner and permissions
RUN chown postgres:postgres /var/lib/postgresql/ssl/* && \
    chmod 600 /var/lib/postgresql/ssl/*

Build this image with docker build -t my-postgres-ssl ., then run it like any other PostgreSQL container. The downside here is that if you need to update your SSL certs, you’ll have to rebuild the image—whereas with volumes, you can just swap out the files on the host and restart the container.

Final Recommendation #

• Go with Option 1 if your SSL certs need to be updated regularly, or if you want to avoid maintaining a custom Docker image.
• Go with Option 2 if your certs are static, or if you need a consistent, pre-configured image for your deployment pipeline.

内容的提问来源于stack exchange，提问作者Charles Langlois