params.yaml

params.yaml

spec:
  serviceClassName: user-provided-service
  planName: default
  parameters:
  - name: username               # easy name/value pair case
    value: root
  - name: password               # pull value from a secret's key
    valueFrom:
      secretKeyRef:
        name: mySecret1
        key: passwd
  - name: size                   # pull value from a configMap key
    valueFrom:
      configMapKeyRef:
        name: myConfigMap0
        key: length
  parametersFrom:
  - configMapRef: myConfigMap1    # pull in all the CM's key/value's   (string/string)
  - secretRef: mySecret2          # pull in all the secret key/value's (string/string)
  - configMapKeyBlobRef:
      name: myConfigMap2
      key: credentials            # "credentials" is a JSON object so we take it verbatim and we merge with the above
  - secretKeyBlobRef:
      name: mySecret3
      key: creds                  # "creds" is a JSON object so we take it verbatim and merge with the the above

Just to demonstrate the consistency between this approach and Pod environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: test-container
    image: nginxdemos/hello
    env:
    - name: USERNAME
      value: root
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mySecret1
          key: passwd
    - name: SIZE
      valueFrom:
        configMapKeyRef:
          name: myConfigMap0
          key: length
    envFrom:
    - configMapRef:
      name: myConfigMap1
    - secretRef:
      name: mySecret2

• there is no analogy for secretKeyBlobRef and configMapKeyBlobRef of course, but the rest maps one-to-one
• envFrom items have prefix attribute, which we might want to leverage as well (for conflict resolution)

This looks like a comprehensive solution for a variety of use cases, I like it.