how to mount secret in openshift with uid:gid set correctly

7/27/2017

I'm using this Dockerfile to deploy it on openshift. - https://github.com/sclorg/postgresql-container/tree/master/9.5

It works fine, until I enabled ssl=on and injected the server.crt and server.key file into the postgres pod via volume mount option.

Secret is created like

$ oc secret new postgres-secrets \
  server.key=postgres/server.key \
  server.crt=postgres/server.crt \
  root-ca.crt=ca-cert

The volume is created as bellow and attached to the given BuidlConfig of postgres.

$ oc volume dc/postgres \
  --add --type=secret \
  --secret-name=postgres-secrets \
  --default-mode=0600 \
 -m /var/lib/pgdata/data/secrets/secrets/

Problem is the mounted files of secret.crt and secret.key files is owned by root user, but postgres expect it should be owned by the postgres user. Because of that the postgres server won't come up and says this error.

waiting for server to start....FATAL: could not load server certificate file "/var/lib/pgdata/data/secrets/secrets/server.crt": Permission denied stopped waiting pg_ctl: could not start server

How we can insert a volume and update the uid:guid of the files in it ?

-- Haridas N
kubernetes
openshift
postgresql
ssl

1 Answer

7/27/2017

It looks like this is not trivial, as it requires to set Volume Security Context so all the containers in the pod are run as a certain user https://docs.openshift.com/enterprise/3.1/install_config/persistent_storage/pod_security_context.html

In the Kubernetes projects, this is something that is still under discussion https://github.com/kubernetes/kubernetes/issues/2630, but seems that you may have to use Security Contexts and PodSecurityPolicies in order to make it work.

I think the easiest option (without using the above) would be to use a container entrypoint that, before actually executing PostgreSQL, it chowns the files to the proper user (postgres in this case).

-- Javier Salmeron
Source: StackOverflow