Merge pull request #25285 from ingvagabund/extend-secrets-volumes-with-path-control

Automatic merge from submit-queue

Extend secrets volumes with path control

As per [1] this PR extends secrets mapped into volume with:

* key-to-path mapping the same way as is for configmap. E.g.

```
{
 "apiVersion": "v1",
 "kind": "Pod",
  "metadata": {
    "name": "mypod",
    "namespace": "default"
  },
  "spec": {
    "containers": [{
      "name": "mypod",
      "image": "redis",
      "volumeMounts": [{
        "name": "foo",
        "mountPath": "/etc/foo",
        "readOnly": true
      }]
    }],
    "volumes": [{
      "name": "foo",
      "secret": {
        "secretName": "mysecret",
        "items": [{
          "key": "username",
          "path": "my-username"
        }]
      }
    }]
  }
}
```

Here the ``spec.volumes[0].secret.items`` added changing original target ``/etc/foo/username`` to ``/etc/foo/my-username``.

* secondly, refactoring ``pkg/volumes/secrets/secrets.go`` volume plugin to use ``AtomicWritter`` to project a secret into file.

[1] https://github.com/kubernetes/kubernetes/blob/master/docs/design/configmap.md#changes-to-secret

pkg/api/v1/generated.proto

@@ -2464,6 +2464,15 @@ message SecretVolumeSource {
   // Name of the secret in the pod's namespace to use.
   // More info: http://releases.k8s.io/HEAD/docs/user-guide/volumes.md#secrets
   optional string secretName = 1;
+
+  // If unspecified, each key-value pair in the Data field of the referenced
+  // Secret will be projected into the volume as a file whose name is the
+  // key and content is the value. If specified, the listed keys will be
+  // projected into the specified paths, and unlisted keys will not be
+  // present. If a key is specified which is not present in the Secret,
+  // the volume setup will error. Paths must be relative and may not contain
+  // the '..' path or start with '..'.
+  repeated KeyToPath items = 2;
 }
 
 // SecurityContext holds security configuration that will be applied to a container.