-
Notifications
You must be signed in to change notification settings - Fork 632
Description
Is there an existing issue already for this feature request/idea?
- I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.
What problem is this feature going to solve? Why should it be added?
In environments where PostgreSQL clusters are designed to be self-service, labels become essential to apply cluster-wide policies such as:
- Kubernetes
NetworkPolicy - Istio
PeerAuthentication - Kyverno or OPA-based policy enforcement
- Admission control via validating/mutating webhooks
Today there are no shared labels across all provisioned cnpg manged pods, meaning that a matchLabels statement cannot target all cnpg managed pods at once. this makes it quite difficult to apply these policies consistently across all provisioned objects.
Describe the solution you'd like
I'd like to request that all pods managed by CloudNativePG be labeled with a consistent, well-known label such as:
app.kubernetes.io/managed-by: cloudnative-pgAdding a well-known label (such as app.kubernetes.io/managed-by: cloudnative-pg) to all pods created by CNPG-managed workloads (e.g. Postgres instances, init pods, wal-archive pods, etc) aligns with Kubernetes label best practices and makes it easier for platform operators to apply consistent policies.
you can find a list of well known recommended labels here: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
Describe alternatives you've considered
Today, it's possible to work around this by using a matchExpressions clause and checking for the existence of the cnpg.io/cluster label, for example:
matchExpressions:
- key: cnpg.io/cluster
operator: ExistsHowever, some systems (such as Istio's PeerAuthentication) do not support matchExpressions and require explicit matchLabels. Without a consistent label, it becomes difficult to safely target only CNPG-managed pods with such policies. Today I am forced to rely on a consumer to add the label, or resort to creating a mutating policy to add the label, while these work, it certainly adds complexity to the process.
Additional context
No response
Backport?
Yes
Are you willing to actively contribute to this feature?
Yes
Code of Conduct
- I agree to follow this project's Code of Conduct
Metadata
Metadata
Assignees
Labels
Type
Projects
Status