New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create secrets in specific namespace #2831
Comments
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? |
Yes, the operator should have access to create secrets in those namespaces. |
Hello, is there any progress about this feature? I think this should be in the |
Seems like a critical enhancement for a security conscious (any) deployment |
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. |
+1 Requesting support for this feature |
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. |
+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. |
(Adding the |
+1 this would be a great feature to have to avoid using third party tools for secrets reflection |
i think the simplest way to handle this is a example:
this would create the thoughts? |
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: Ensure that the reconcile function knows what to do with it: 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 |
I really like the behavior of cert-manager's This then works together with tools like Reflector such that the secret can be arbitrarily copied to other 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.
While this would work, I think it is not optimal, since the secret may be needed in multiple namespaces. |
I ended up using jsPolicy to inject Reflector 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: {} |
I thinks it should be more explicit i.e |
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.
The text was updated successfully, but these errors were encountered: