Enhance k8s secrets management by Ops

Currently, k8s secrets are not committed to the Git repo (since they are secrets). When a new stack is created, the secret is created locally and applied to the k8s cluster.

Nota: a k8s secret is a set of key/value.

Now that we are two Ops, this poses the problem that not all Ops have all secrets. This makes production maintenance more tedious since once in a while we have to retrieve a secret we do not have locally to update it.

But this also poses a significant operational risk of errors. A scenario is that Ops 1 might have created the secret (and hence have a local version), Ops 2 might alter the secret, and when Ops 1 come back to update the secret again, if he does not retrieve the secret first (because he already has a local copy), he will overwrite the change made by Ops 2. If keys manipulated by Ops1 and Ops2 are not the same, the last change from Ops1 will hence have an unexpected change.

To help us on both aspects mentioned above in an efficient way, we could have a small tool which retrieves all secrets locally and a process which says that before updating a secret, we must run this tool to ensure consistency.

No files, tests, or entry points are named. Start by reviewing how new stacks currently create local secrets and apply them to the Kubernetes cluster, then define the retrieval tool and update process; done means Ops can synchronize all secrets locally before making changes without overwriting another operator’s updates.

Written by the indexing model from the issue text.