<p>I am using docker and kubernetes on Google Cloud Platform, with the Kubernetes Engine.
I have secrets configurated in a app.yaml file like so :</p>

<pre><code>apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
  namespace: $CI_COMMIT_REF_SLUG
  labels:
    app: app
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: gcr.io/engagement-org/app:$CI_COMMIT_SHA
        imagePullPolicy: Always
        ports:
        - containerPort: 9000
        env:
        - name: MAILJET_APIKEY_PUBLIC
          valueFrom:
            secretKeyRef:
              name: mailjet
              key: apikey_public
        - name: MAILJET_APIKEY_PRIVATE
          valueFrom:
            secretKeyRef:
              name: mailjet
              key: apikey_private
</code></pre>

<p>Each time I push on a new branch, a new namespace is created through a deploy in my gitlab-ci file. Secrets are created like so :</p>

<pre><code> - kubectl create secret generic mailjet --namespace=$CI_COMMIT_REF_SLUG --from-literal=apikey_public=$MAILJET_APIKEY_PUBLIC --from-literal=apikey_private=$MAILJET_APIKEY_PRIVATE || echo 'Secret already exist'; 
</code></pre>

<p>Now, I have updated my mailjet api keys and want to make the change to all namespaces.
I can edit the secret on each namespace by getting a shell on the pods and running <code>kubectl edit secret mailjet --namespace=&lt;namespace_name&gt;</code></p>

<p>What I want is to send the new secret values to the new pods that will be created in the future. When I deploy a new one, it still uses the old values.</p>

<p>From what I understand, the gitlab-ci file uses the app.yaml file to replace the environment variables with values. But I don't understand where app.yaml finds the original values.</p>

<p>Thank you for your help.</p>

<p>In general, Kubernetes namespaces are designed to provide isolation for components running inside them. For this reason, the Kubernetes API is not really designed to perform update operations across namespaces, or make secrets usable across namespaces.</p>

<p>That being said, there are a few things to solve this issue.</p>

<h3>1. Use a single namespace &amp; Helm releases instead of separate namespaces</h3>

<p>From the looks of it, you are using Gitlab CI to deploy individual branches to review environments (presumably using Gitlab's <a href="https://docs.gitlab.com/ee/ci/review_apps/" rel="noreferrer">Review App</a> feature?). The same outcome can be achieved by deploying all Review Apps into the same namespace, and using <a href="https://helm.sh/" rel="noreferrer">Helm</a> to manage multiple deployments ("releases" in Helm-speak) of the same application within a single namespace.</p>

<p>Within the <code>gitlab-ci.yml</code>, creating a Helm release for a new branch might look similar to this:</p>

<pre><code>script:
- helm upgrade --namespace default --install review-$CI_COMMIT_REF_SLUG ./path/to/chart
</code></pre>

<p>Of course, this requires that you have defined a <a href="https://docs.helm.sh/developing_charts/#charts" rel="noreferrer">Helm chart</a> for your application (which, in essence is just a set of YAML templates with a set of default variables that can then be overridden for individual releases). Refer to the documentation (linked above) for more information on creating Helm charts.</p>

<h3>2. Keep secrets in sync across namespaces</h3>

<p>We have had a similar issue a while ago and resorted to writing a custom Kubernetes controller that keeps secrets in sync across namespaces. It's open source and you can <a href="https://github.com/mittwald/kubernetes-replicator" rel="noreferrer">find it on GitHub</a> (use with caution, though). It is based on annotations and provides unidirectional propagation of changes from a single, authoritative parent secret:</p>

<pre><code>apiVersion: v1
kind: Secret
metadata:
  name: mailjet
  namespace: some-kubernetes-namespace
  annotations:
    replicator.v1.mittwald.de/replicate-from: default/mailjet
</code></pre>

<p>With the secret replicator deployed in your cluster, using this annotation will propagate all changes made to the <code>mailjet</code> secret in the <code>default</code> namespace to all secrets in any namespaced annotated like show above.</p>
