1

I have a ClusterIssuer that is expecting secretName, I see in the ClusterIssuer spec, I can specify the secretName:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: postgres-operator-ca-certificate-cluster-issuer
spec:
  ca:
    secretName: postgres-operator-ca-certificate     # <---- Here

but how to provide the reference to the secret namespace? This secret is created using Certificate:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: postgres-operator-self-signed-ca-certificate
  namespace: postgres                 # <---- This namespace can not be changed to cert-manager
spec:
  isCA: true
  commonName: postgres-operator-ca-certificate
  secretName: postgres-operator-ca-certificate
  issuerRef:
    name: postgres-operator-selfsigned-clusterissuer
    kind: ClusterIssuer

As this is namespaced is the suggestion is to use Issuer instead of ClusterIssuer? Does ClusterIssuer by default look in the cert-manager namespace?

Vishrant
  • 15,456
  • 11
  • 71
  • 120
  • If I use `Issuer` that will solve the issue, but is there a way to use `ClusterIssuer` instead – Vishrant Sep 23 '22 at 21:38
  • in my case we are using reflector, feel free to take a look here: https://github.com/emberstack/kubernetes-reflector/blob/main/README.md – jmvcollaborator Sep 24 '22 at 03:01

1 Answers1

3

Typically it will look for the secret in the namespace cert-manager by default. Which namespace it looks in can be changed by your cert-manager installation by using the --cluster-resource-namespace argument, but not by individual ClusterIssuer.

From the documentation:

If the referent is a cluster-scoped resource (e.g. a ClusterIssuer), the reference instead refers to the resource with the given name in the configured ‘cluster resource namespace’, which is set as a flag on the controller component (and defaults to the namespace that cert-manager runs in).

https://cert-manager.io/docs/reference/api-docs/#meta.cert-manager.io/v1.LocalObjectReference

ericfossas
  • 1,511
  • 8
  • 12
  • Thanks! That's a feasible solution, but that will make cert-manager not reusable by other services if they are on a different namespace. +1 but can not accept as an answer. – Vishrant Sep 26 '22 at 00:13
  • @Vishrant i didn't offer a solution, i answered your question about ClusterIssuers, secrets, and namespaces. What question/problem are you looking for an answer to? – ericfossas Sep 26 '22 at 15:25
  • The `Certificate` is a namespaced object, the secret will get created in the same ns where the Certificate has been created, the `ClusterIssuer` has no namespace, but it expects the secrets to be in `cert-manager`, which is contradictory. There should be a way in the ClusterIssuer to specify the ns for the secret that it's trying to sign. The question is there is a way to let ClusterIssuer object know where to look for a secret without changing the Certificate ns or specifying `cluster-resource-namespace` (cluster-resource-namespace will add limitation for other applications) – Vishrant Sep 28 '22 at 19:23
  • the answer to that is no. there is no way to do that. in my experience, people turn to an operator to copy/sync secrets among different namespaces to solve the overall problem you have. there are multiple tools that do this. – ericfossas Sep 28 '22 at 20:19
  • having another operator to achieve it will be over-engineering. I think the changes should be made in the cert-manager injector itself. But thanks for your thoughts. – Vishrant Sep 29 '22 at 00:25