kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor addendums to secrets proposal

This commit is contained in:
Paul Morie 2015-02-19 10:25:13 -05:00
parent 77211be2c0
commit e6e17729be
1 changed files with 21 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
secrets.md
View File

@ -29,6 +29,8 @@ Goals of this design:
secrets belonging to containers scheduled onto it secrets belonging to containers scheduled onto it
* If the master is compromised, all secrets in the cluster may be exposed * If the master is compromised, all secrets in the cluster may be exposed
* Secret rotation is an orthogonal concern, but it should be facilitated by this proposal * Secret rotation is an orthogonal concern, but it should be facilitated by this proposal
* A user who can consume a secret in a container can know the value of the secret; secrets must
be provisioned judiciously
## Use Cases ## Use Cases
@ -270,10 +272,12 @@ type Secret struct {
TypeMeta TypeMeta
ObjectMeta ObjectMeta
// Keys in this map are the paths relative to the volume // Data contains the secret data. Each key must be a valid DNS_SUBDOMAIN.
// presented to a container for this secret data. // The serialized form of the secret data is a base64 encoded string.
Data map[string][]byte Data map[string][]byte `json:"data,omitempty"`
Type SecretType
// Used to facilitate programatic handling of secret data.
Type SecretType `json:"type,omitempty"`
} }
type SecretType string type SecretType string
@ -291,7 +295,8 @@ const MaxSecretSize = 1 * 1024 * 1024
A Secret can declare a type in order to provide type information to system components that work A Secret can declare a type in order to provide type information to system components that work
with secrets. The default type is `opaque`, which represents arbitrary user-owned data. with secrets. The default type is `opaque`, which represents arbitrary user-owned data.
Secrets are validated against `MaxSecretSize`. Secrets are validated against `MaxSecretSize`. The keys in the `Data` field must be valid DNS
subdomains.
A new REST API and registry interface will be added to accompany the `Secret` resource. The A new REST API and registry interface will be added to accompany the `Secret` resource. The
default implementation of the registry will store `Secret` information in etcd. Future registry default implementation of the registry will store `Secret` information in etcd. Future registry
@ -325,6 +330,11 @@ type SecretSource struct {
Secret volume sources are validated to ensure that the specified object reference actually points Secret volume sources are validated to ensure that the specified object reference actually points
to an object of type `Secret`. to an object of type `Secret`.
In the future, the `SecretSource` will be extended to allow:
1. Fine-grained control over which pieces of secret data are exposed in the volume
2. The paths and filenames for how secret data are exposed
### Secret Volume Plugin ### Secret Volume Plugin
A new Kubelet volume plugin will be added to handle volumes with a secret source. This plugin will A new Kubelet volume plugin will be added to handle volumes with a secret source. This plugin will
@ -382,13 +392,14 @@ To create a pod that uses an ssh key stored as a secret, we first need to create
"kind": "Secret", "kind": "Secret",
"id": "ssh-key-secret", "id": "ssh-key-secret",
"data": { "data": {
"id_rsa.pub": "dmFsdWUtMQ0K", "id-rsa.pub": "dmFsdWUtMQ0K",
"id_rsa": "dmFsdWUtMg0KDQo=" "id-rsa": "dmFsdWUtMg0KDQo="
} }
} }
``` ```
**Note:** The values of secret data are encoded as base64-encoded strings. **Note:** The values of secret data are encoded as base64-encoded strings. Newlines are not
valid within these strings and must be omitted.
Now we can create a pod which references the secret with the ssh key and consumes it in a volume: Now we can create a pod which references the secret with the ssh key and consumes it in a volume:
@ -432,8 +443,8 @@ Now we can create a pod which references the secret with the ssh key and consume
When the container's command runs, the pieces of the key will be available in: When the container's command runs, the pieces of the key will be available in:
/etc/secret-volume/id_rsa.pub /etc/secret-volume/id-rsa.pub
/etc/secret-volume/id_rsa /etc/secret-volume/id-rsa
The container is then free to use the secret data to establish an ssh connection. The container is then free to use the secret data to establish an ssh connection.