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=
Then I could include them like:
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: PASSWORDAnd use them in Node.js app like process.env.JOHN_USERNAME, etc..
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.
You can mount the secret as a volume. Adapting the example from the linked Kubernetes documentation:
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-secretIf you have a bunch of secrets, you'd need to mount them all into the pod spec. That's a maintainability problem in itself.
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.
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 Vault 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.