Missing /etc/pg_hardstorage/keyring/ in ConfigMap

[sebastiansuter-advact]

What happened

ConfigMap (https://github.com/cybertec-postgresql/pg_hardstorage/blob/main/charts/pg-hardstorage-sidecar/templates/configmap.yaml) only templates pg_hardstorage.yaml but not /etc/pg_hardstorage/keyring/

The documentation states that the keyring is part of the ConfigMap (https://github.com/cybertec-postgresql/pg_hardstorage/blob/main/docs/how-to/kubernetes/helm-sidecar-chart.md#inline-keyring-small-deployments)

The keyring directory /etc/pg_hardstorage/keyring/ mounts as part of the ConfigMap. Useful for plaintext-only setups or for a passphrase wrapper backed by a sealed Secret.

To reproduce

Install latest version of the sidecar chart and inspect the ConfigMap. It does not contain the keyring

pg_hardstorage version

v1.1.1

Environment

Kubernetes Cluster with latest version of the sidecar chart installed

Anything else

At the moment there is no good way to persist the keyring data for kek_ref: local:default. The ConfigMap does not template the keyring and the StatefulSet does not allow any configurable mounts besides state.

There are also no env variables like KEYSTORE_* that can reference the public/privte signing-key or kek.bin, therefore not allowing the option to pass there values with env: in the chart.

Honestly I'd prefer passing the values through the env: in the chart than paintext in the ConfigMap. But ideally additional mounts with secretRefs in the StatefulSet would provide an option to pass the three paramteres (private, public, kek) to the container.

[sebastiansuter-advact]

Using a deployment to test mounting the secrets fails, as permissions will always be 06400 with fsGroup. Given an alpine deployment with the following volumes / volumeMounts:

      volumeMounts:
          - name: pg-hardstorage-keyring
            mountPath: /mnt
            readOnly: true
      volumes:
        - name: pg-hardstorage-keyring
          secret:
            secretName: pg-hardstorage-keyring
            defaultMode: 0600
            items:
              - key: manifest_signing.ed25519
                path: manifest_signing.ed25519
              - key: manifest_signing.pub
                path: manifest_signing.pub
              - key: kek.bin
                path: kek.bin

will result in the following permissions:

~ $ ls -la /mnt
total 0
drwxrwsrwt    3 root     65532          140 Aug  6 09:09 .
drwxr-xr-x    1 root     root            39 Aug  6 09:09 ..
drwxr-sr-x    2 root     65532          100 Aug  6 09:09 ..2026_08_06_09_09_38.339041719
lrwxrwxrwx    1 root     65532           31 Aug  6 09:09 ..data -> ..2026_08_06_09_09_38.339041719
lrwxrwxrwx    1 root     65532           14 Aug  6 09:09 kek.bin -> ..data/kek.bin
lrwxrwxrwx    1 root     65532           31 Aug  6 09:09 manifest_signing.ed25519 -> ..data/manifest_signing.ed25519
lrwxrwxrwx    1 root     65532           27 Aug  6 09:09 manifest_signing.pub -> ..data/manifest_signing.pub

~ $ ls -la /mnt/..data/
total 12
drwxr-sr-x    2 root     65532          100 Aug  6 09:09 .
drwxrwsrwt    3 root     65532          140 Aug  6 09:09 ..
-rw-r-----    1 root     65532           32 Aug  6 09:09 kek.bin
-rw-r-----    1 root     65532          165 Aug  6 09:09 manifest_signing.ed25519
-rw-r-----    1 root     65532          159 Aug  6 09:09 manifest_signing.pub

The pg_hardstorage binary follows the symlinks correctly, but kubernetes will only crate files with 06400 root nobody. So I think that it will not be possible to mount secrets like this. The same issue with templating the keyring through the ConfigMap:

~ $ ls -la /proc/1/root/etc/pg_hardstorage/
total 8
drwxrwsrwx    3 root     65532         4096 Aug  6 07:00 .
drwxr-xr-x    1 root     root            76 Aug  6 07:04 ..
drwxr-sr-x    2 root     65532         4096 Aug  6 07:00 ..2026_08_06_07_00_37.3346087377
lrwxrwxrwx    1 root     65532           32 Aug  6 07:00 ..data -> ..2026_08_06_07_00_37.3346087377
lrwxrwxrwx    1 root     65532           26 Aug  6 07:00 pg_hardstorage.yaml -> ..data/pg_hardstorage.yaml
~ $ ls -la /proc/1/root/etc/pg_hardstorage/..data/
total 12
drwxr-sr-x    2 root     65532         4096 Aug  6 07:00 .
drwxrwsrwx    3 root     65532         4096 Aug  6 07:00 ..
-rw-r--r--    1 root     65532          416 Aug  6 07:00 pg_hardstorage.yaml

The simples solution would probably be:

• Create the /etc/pg_hardstorage/keyring/ directory in the Dockerfile, it is missing. Then expand the StatefulSet to allow a PVC to be mounted there. Leave it to the operator to populate the keyring PVC.