PGPassSecretRef references a Secret containing a pre-created pgpass file.
Why this is a dedicated field instead of a regular volume/volumeMount:
PostgreSQL's libpq rejects pgpass files that aren't mode 0600. Kubernetes
secret volumes mount files as root-owned, and the registry-api container
runs as non-root (UID 65532). A root-owned 0600 file is unreadable by
UID 65532, and using fsGroup changes permissions to 0640 which libpq also
rejects. The only solution is an init container that copies the file to an
emptyDir as the app user and runs chmod 0600. This cannot be expressed
through volumes/volumeMounts alone -- it requires an init container, two
extra volumes (secret + emptyDir), a subPath mount, and an environment
variable, all wired together correctly.
When specified, the operator generates all of that plumbing invisibly.
The user creates the Secret with pgpass-formatted content; the operator
handles only the Kubernetes permission mechanics.
Example Secret:
apiVersion: v1
kind: Secret
metadata:
name: my-pgpass
stringData:
.pgpass: |
postgres:5432:registry:db_app:mypassword
postgres:5432:registry:db_migrator:otherpassword
Then reference it:
pgpassSecretRef:
name: my-pgpass
key: .pgpass
key
string required
The key of the secret to select from. Must be a valid secret key.
name
string
Name of the referent.
This field is effectively required, but due to backwards compatibility is
allowed to be empty. Instances of this type with an empty value here are
almost certainly wrong.
More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
optional
boolean
Specify whether the Secret or its key must be defined