<pre><code>apiVersion: v1
kind: Secret
metadata:
  name: john-secret
data:
  USERNAME: abc=
  PASSWORD: def=

apiVersion: v1
kind: Secret
metadata:
  name: jane-secret
data:
  USERNAME: ghi=
  PASSWORD: jkl=
</code></pre>

<p>Then I could include them like:</p>

<pre><code>env:
  - name: JOHN_USERNAME
    valueFrom:
      secretKeyRef:
        name: john-secret
        key: USERNAME
  - name: JOHN_PASSWORD
    valueFrom:
      secretKeyRef:
        name: john-secret
        key: PASSWORD
  - name: JANE_USERNAME
    valueFrom:
      secretKeyRef:
        name: jane-secret
        key: USERNAME
  - name: JANE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: jane-secret
        key: PASSWORD
</code></pre>

<p>And use them in Node.js app like <code>process.env.JOHN_USERNAME</code>, etc..</p>

<p>This works, but is there a cleaner/easier way to set secrets for a bunch of users that will have multiple fields? I imagine this would get messy with say 100 users x 5 fields.</p>

atkayla
<p>You can <a href="https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume" rel="nofollow noreferrer">mount the secret as a volume</a>.  Adapting the example from the linked Kubernetes documentation:</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: nginx
      volumeMounts:
          - name: john-secret
            mountPath: /etc/john-secret
  volumes:
    - name: secret-volume
      secret:
        secretName: john-secret
</code></pre>

<p>If you have a bunch of secrets, you'd need to mount them all into the pod spec.  That's a maintainability problem in itself.</p>

<p>I don't think anything actually stops you from using a more structured data object, like a JSON or YAML file, as the value of a secret.  That could work reasonably in combination with mounting it as a volume.</p>

<p>If you truly have a lot of secrets – many "users" with many values for each – then some sort of external storage for the secrets is probably a better idea.  If they're just usernames and passwords, it's very common to store a one-way hash of the password in a database (which also allows them to be updated without redeploying the system).  Tools like Hashicorp's <a href="https://vaultproject.io/" rel="nofollow noreferrer">Vault</a> can be complicated to administer, but have actual security of this content as a priority, and you get much more rigorous control over who can access the actual secrets.</p>
