zalando / zalando/postgres-operator
Mount client certificate with correct ownership
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 5.2k
- Forks
- 1.1k
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 3
Description
Postgres operator image: 1.5.0
I run on: Bare metal
Running on prod: Yes, but this issue is not related to production
Type of issue: question / feature request
Hello, I work on mutual-TLS with logical replication between two postgres clusters and faced the following issue I can't solve:
I have two postgresql clusters running in separate namespaces: cluster X & cluster Y.
X is a "server" for logical replication, it has publication created and requires client certificate.
Y is a "client" for logical replication, it has subscription created and needs to have CA mounted (for server cert verification) as well as client key & cert to let server authenticate the client.
And here's the problem: When I create subscription, it requires client key to have proper permissions (0600). And this is impossible to achieve without manual changes after container is started up.
When I mount secret with client cert (either by tls or by additionalVolumes), it's created with root ownership (psql runs on postgres user and requires postgres ownership and proper permissions). Thought about other tricks like containerPostStart but I'm also unable to define it in postgres resource manifest.
When I do copy->paste->chown->chmod everything works like a charm, but I need to get rid of this manual step.
Is there any chance to get client TLS mounted with proper permissions & ownership?
Thanks.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Postgres resource manifest and the tls and additionalVolumes settings; inspect how mounted client certificates and keys receive ownership and permissions. Compare this with the containerPostStart limitation, with done defined as a supported manifest configuration that gives the postgres user access and keeps the client key at mode 0600.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, postgresql
- Domain
- databases, infrastructure, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100