# TLS changes, would it need manual restart or automatic restart of operator?

**URL:** <https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968>\
**Category:** Kubernetes Operator\
**Created:** [May 17, 2023, 1:02pm UTC](https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968 "2023-05-17T13:02:34Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [May 17, 2023, 1:02pm UTC](https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968/1 "2023-05-17T13:02:34Z")

</div>

Hi,  
When the TLS is changed/refreshed (the content is changed, the cert is mounted through secret), would the operator restart itself and reconcile the cluster due to using the new cert?

---

<div class="post-metadata">

**Author:** ![johscheuer](https://avatars.discourse-cdn.com/v4/letter/j/f475e1/32.png) [@johscheuer](https://forums.foundationdb.org/u/johscheuer)\
**Post date:** [May 17, 2023, 1:07pm UTC](https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968/2 "2023-05-17T13:07:24Z")

</div>

When the certificate or key is changed the operator should automatically pickup the new content the next time it tries to communicate with the FDB cluster or one of the sidecars. For the sidecars the certificate is always loaded: [fdb-kubernetes-operator/pod\_client.go at main · FoundationDB/fdb-kubernetes-operator · GitHub](https://github.com/FoundationDB/fdb-kubernetes-operator/blob/main/internal/pod_client.go#L141-L144) and the fdbclient should also refresh the certificate and key if it is changed.

---

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [May 17, 2023, 3:14pm UTC](https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968/3 "2023-05-17T15:14:07Z")

</div>

Another question, we mount TLS cert in both operator and fdb itself. So, it is required for operation purpose like starting and stopping the operand? Why does it need the cert between the operator and operand as the operand only need the cert for communicate to outside. Wouldn’t it should be ok if only RBAC is there for communication and control?

---

<div class="post-metadata">

**Author:** ![johscheuer](https://avatars.discourse-cdn.com/v4/letter/j/f475e1/32.png) [@johscheuer](https://forums.foundationdb.org/u/johscheuer)\
**Post date:** [May 22, 2023, 6:08am UTC](https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968/4 "2023-05-22T06:08:19Z")

</div>

What exactly do you mean with the `operand`? The operator needs the TLS setup to communicate with the FoundationDB cluster (if enabled) and the sidecars (if enabled).

> Wouldn’t it should be ok if only RBAC is there for communication and control?

If you mean Kubernetes RBAC, this is only used for access control for Kubernetes resources not for the sidecar or the FoundationDB cluster. Adopting RBAC would be more challenging and probably requires some additional tooling.

---

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [May 23, 2023, 2:44pm UTC](https://forums.foundationdb.org/t/tls-changes-would-it-need-manual-restart-or-automatic-restart-of-operator/3968/5 "2023-05-23T14:44:50Z")

</div>

So, the operator needs the TLS to function (like start/stop fdb pods) since it needs to communicate with them.  
The issue I am facing is that, we are creating a second namespace and put the fdb operator in there and reassign the old pods to this new operator. The cert is not there at the start and it was apply to the setup with a new cert. At this moment, the operator can no longer talk to the pods since the cert is different and it stuck. Restarting the operator created a new set of fdb pods with the new cert but the old set of pods remains.  
So, is there a way to get around it?
