How to reuse TLS certificate from another namespace

How do I?
1

This part of docs says we can reuse certificate generated by installer. We deploy application to separate from default namespace (which is strongly recommended here Managing Application Namespaces | Replicated Docs) and it’s impossible to get secret from default namespace. What the best way to share certificate?

2

Hi @Vitaliy thanks for this question – I think maybe the docs might need some clarification, but if you look at the first example, our recommendation is to never specify a namespace in your manifests, and have the App Manager (KOTS) deploy to whatever namespace it’s running in. Would you be able to give that a try?

# good, namespace absent
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spline-reticulator
spec:

However, if you must use another namespace, I believe you can use the additionalNamespaces flag documented for the kots.io Application Custom Resource to cause certain secrets to be copied across namespaces, but I don’t think the kurl-proxy SSL secret is one of these.

3

Thank you for your answer.
Let me be more specific. App Manager is deployed into default namespace, when my helm chart is deployed into dedicated namespace (we have ‘namespace:’ is absent in our templates, but have ‘additionalNamespaces:’ in ‘replicated-app.yaml’ and ‘namespace:’ provided in ‘helm-chart.yaml’ file). App Manager creates secret object ‘kotsadm-tls’ with certificate in default namespace and doesn’t share it with additional namespaces. So the only one solution is to deploy my helm chart into default namespace to share those certificates?

4

Hi Vitaliy – I think its less “you must use the default namespace”, but more so, “you should use the same namespace that the App Manager (KOTS) is deployed to”. In the kURL cluster case, this will always be the default namespace, but just want to clarify that one detail. So I would leave out the namespace in your HelmChart kind, or set it to {{repl Namespace }} to pick up the KOTS namespace automatically.

5

Hello @dex,
I know this post is a little old. But, I have this requirement too.
In my case, our application has an operator, which gets deployed to one namespace and then, there is a second namespace which is used by the operator to deploy the app.

My scenario is to copy the TLS secret to the second namespace. Currently, I am manually copying the secret kotsadm-tls using kubectl to the second (app) namespace.

If there’s a way to copy kotsadm-tls to additional namespaces, that would be really helpful.

Best Regards,
Ravi

6

Hi Ravi – I’m not sure if it was mentioned, but there are vendors who do this today by including a small (custom-build) controller that moves this secret around. You could also copy this logic into your operator itself.

Is there a strong architectural reason that your operator needs to deploy workloads in a separate namespace? I know this is a common pattern with some benefits, but I would consider those benefits in conjunction with the drawbacks of having to write custom code for this, and for the extra hurdles you may see in enterprise environments when you require cross-namespace RBAC access. For example, many enterprises are not willing to grant 3rd party apps the ClusterRole to create and manage namespaces.

Again, these are all tradeoffs, best I can do is lay out the two options. If you would be interested in open sourcing a controller to copy the secret around, you might get the interest of some folks from our team as co-maintainers.

7

Hello @dex,

I am also looking at options to deploy both our operator and the apps into a single namespace. I am checking with my team internally to see if there are any impacts (not just technically, but documentation side also). if there is no or minimal impact, I’ll go ahead with your suggestion of using the KOTS namespace.

If the impact is big, I was thinking of using something like Cluster Secret. But, again, doing this for just one secret is also not worth it.

I’ll see how it goes. :slight_smile: