Create secrets in specific namespace

[synchris]

A way to instruct the operator to create a secret in a specific namespace for the user and database mentioned in the CRD configuration. So will diminish the need to use SecretImport SecretExport for instance as it creates a lot of hustle. This will help to separate the PostgreSQL cluster to different namespaces from the running applications.

[jkatz]

This could be doable. It does mean that you would have to give the Operator privileges to interact with the application Namespaces. Would that be acceptable?

[synchris]

Yes, the operator should have access to create secrets in those namespaces.

[budimanjojo]

Hello, is there any progress about this feature? I think this should be in the PostgresCluster.spec.users.secretNamespaces as []string and it defaulted to the namespace of cluster if not defined. It's very common that the container the user want to connect to is not in the namespace of the postgresCluster.

[B1ue-W01f]

Seems like a critical enhancement for a security conscious (any) deployment

[philmccOri]

This is a critical feature for me as well. I'd like to switch to this operator but we use multiple apps running in different namespaces which makes it difficult to retrieve their passwords from a single namespace.

[azharullah]

+1 Requesting support for this feature

[andrewlecuyer]

Thanks for all of the feedback and input on this one. Just noting that a story has been added to the PGO backlog for consideration in a future release.

[AlisaAkiron]

+1 It's a critical feature for me.

Or, I think adding custom annotations to the secret is also an ok choice, so that we can use tools like kubernetes-reflector to mirror the secret to another namespace.

[benjaminjb]

(Adding the backlog label just to indicate that we have this feature in our backlog and are tracking it.)

[kaizendae]

+1 this would be a great feature to have to avoid using third party tools for secrets reflection

[sgraham785]

i think the simplest way to handle this is a . split in the users[].name

example:

users:
    - name: rhino
      databases:
        - zoo
    - name: default.blah
       databases:
       - zoo

this would create the zoo database and users rhino and blah deploying the user pass for rhino in the PGO deployed ns and the user blah secret to the default namespace

thoughts?

[jaitaiwan]

I was looking at what it would take to make this happen. So far what I can see is that one would need to add a new part to the spec: https://github.com/jaitaiwan/postgres-operator/blob/master/pkg/apis/postgres-operator.crunchydata.com/v1beta1/postgres_types.go#L41

Ensure that the reconcile function knows what to do with it: https://github.com/jaitaiwan/postgres-operator/blob/master/internal/controller/postgrescluster/postgres.go#L321

I don't see anywhere else at first glance that needs any changes apart from any tests or e2e that might need to be done

[meyfa]

I really like the behavior of cert-manager's Certificate resource, which allows you to specify labels and annotations for the secret: https://cert-manager.io/docs/usage/certificate/

This then works together with tools like Reflector such that the secret can be arbitrarily copied to other namespaces:

apiVersion: cert-manager.io/v1
kind: Certificate
...
spec:
  secretTemplate:
    annotations:
      reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
      reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: ""
  ...

The added benefit is that annotations and labels can be added for other purposes as well. Also, nothing about the operator's permissions regarding other namespaces needs to change.

i think the simplest way to handle this is a . split in the users[].name

While this would work, I think it is not optimal, since the secret may be needed in multiple namespaces.

[sunsided]

I ended up using jsPolicy to inject Reflector reflector.v1.k8s.emberstack.com/reflection-allowed annotations into the secret created by Postgres Operator. In this case for the user keycloak with secret reflection allowed into the keycloak namespace:

type: Mutating
operations: ["CREATE"]
resources: ["secrets"]
scope: "Namespaced"
namespaceSelector:
  matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values: ["postgres-operator"]
javascript: |
  if (!request.name.endsWith("-pguser-keycloak")) {
    exit();
  }

  const secret = request.object;
  const annotations = secret.metadata.annotations || {};

  const hasAnnotation = !!annotations['reflector.v1.k8s.emberstack.com/reflection-allowed'];

  if (hasAnnotation) {
    exit();
  }

  const reflectorSettings = {
    "reflector.v1.k8s.emberstack.com/reflection-allowed": "true",
    "reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces": "keycloak"
  };

  secret.metadata.annotations = {
    ...annotations,
    ...reflectorSettings
  };

  mutate(secret);

The mirror target then looks like e.g.

apiVersion: v1
kind: Secret
metadata:
 name: some-name
 namespace: keycloak
 annotations:
   reflector.v1.k8s.emberstack.com/reflects: "postgres-operator/hippo-pguser-keycloak"
data: {}

[itsSaad]

i think the simplest way to handle this is a . split in the users[].name

example:

users:
    - name: rhino
      databases:
        - zoo
    - name: default.blah
       databases:
       - zoo

this would create the zoo database and users rhino and blah deploying the user pass for rhino in the PGO deployed ns and the user blah secret to the default namespace

thoughts?

I thinks it should be more explicit i.e namespace. default.blah seems too cryptic. But really hoping this can be released sooner.