[medazizktata25]

Extracted unchanged from a larger branch about bootstrapping the lazy clone in-pod over loopback. The TLS change does not depend on any of that work and should not wait for it. Authored by khalil tbini; I cherry-picked it, so the author is preserved and the diff is byte-identical to the original commit's.

What it does

A wrapper entrypoint starts Postgres with ssl=on and either a mounted cert pair (GFS_TLS_CERT_FILE/GFS_TLS_KEY_FILE, defaulting to /etc/gfs-tls/tls.{crt,key}) or a per-container self-signed pair, then execs the stock docker-entrypoint.sh. Clients can then use sslmode=require.

TLS is offered, not forced, and the script says why: kube-proxy SNATs NodePort traffic, so pg_hba cannot distinguish an internet client from an in-cluster one. Encryption is enforced on the client side, through the connection string.

No private key is baked into the image — the self-signed pair is generated per container, so there is no shared key across deployments.

Verified against the built image

Built from this branch and exercised directly, not reasoned about:

Default start, self-signed

show ssl                                    -> on
show ssl_cert_file                          -> /var/lib/gfs-tls/server.crt
psql '...?sslmode=require' -c 'select 1'    -> 1
select ssl from pg_stat_ssl ... backend     -> t      (actually encrypted, not merely offered)
stat server.key                             -> 600 postgres
pg_available_extensions where name='gfs'     -> 1      (the extension still loads)

A mounted pair must win over the self-signed one — mounted a throwaway cert with CN=mounted-wins:

openssl x509 -subject -in server.crt        -> subject=CN=mounted-wins
psql '...?sslmode=require' -c 'select 1'    -> 1

Other commands must pass through, not be swallowed by the wrapper

docker run <image> psql --version           -> psql (PostgreSQL) 17.11

The script also parses cleanly under dash, which is /bin/sh on the Debian base — worth checking separately because it is written for sh, not bash, and runs under set -eu.

What is NOT verified

• The Kubernetes path. Everything above is plain docker run. The NodePort/SNAT reasoning in the script's comment is the stated rationale for offering rather than forcing TLS, and I did not exercise it on a cluster.
• sslmode=verify-full against a real CA-issued wildcard. The mounted-cert path is verified to take effect; whether a given CA chain satisfies a verifying client is a deployment question.
• Non-root containers. The script branches on id -u for both the certificate directory and the chown, and the image runs as root here, so that branch was not taken. I checked separately that the [ "$(id -u)" = 0 ] && chown ... line does not abort the script under set -e on dash — it does not, so the non-root path should reach the exec — but it is untested on an actual non-root start.