Extend the current secrets mounting to volume implementation with key to path mapping.

The key to path mapping allows pod to specify different name (thus location) of each secret.
At the same time refactor the volume plugin to use AtomicWritter to project secrets to files in a volume.

Update e2e Secrets test, the secret file permission has changed from 0444 to 0644
Remove TestPluginIdempotent as the AtomicWritter is responsible for secret creation
This commit is contained in:
Jan Chaloupka
2016-05-06 21:17:27 +02:00
parent e4e6e46197
commit ebe56f5ff9
5 changed files with 221 additions and 109 deletions

View File

@@ -582,6 +582,14 @@ type GitRepoVolumeSource struct {
type SecretVolumeSource struct {
// Name of the secret in the pod's namespace to use.
SecretName string `json:"secretName,omitempty"`
// 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 '..'.
Items []KeyToPath `json:"items,omitempty"`
}
// Represents an NFS mount that lasts the lifetime of a pod.