Skip to content

[Feature]: Add standard label to all CNPG-managed pods for policy targeting #8066

@JefeDavis

Description

@JefeDavis

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-pg

Adding 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: Exists

However, 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

Projects

Status

Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions