Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Minor addendums to secrets proposal #4600

Merged
merged 1 commit into from
Feb 19, 2015
Merged

Minor addendums to secrets proposal #4600

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
31 changes: 21 additions & 10 deletions docs/design/secrets.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,8 @@ Goals of this design:
secrets belonging to containers scheduled onto it
* 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
* A user who can consume a secret in a container can know the value of the secret; secrets must
be provisioned judiciously

## Use Cases

Expand Down Expand Up @@ -270,10 +272,12 @@ type Secret struct {
TypeMeta
ObjectMeta

// Keys in this map are the paths relative to the volume
// presented to a container for this secret data.
Data map[string][]byte
Type SecretType
// Data contains the secret data. Each key must be a valid DNS_SUBDOMAIN.
// The serialized form of the secret data is a base64 encoded string.
Data map[string][]byte `json:"data,omitempty"`

// Used to facilitate programatic handling of secret data.
Type SecretType `json:"type,omitempty"`
}

type SecretType string
Expand All @@ -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
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
default implementation of the registry will store `Secret` information in etcd. Future registry
Expand Down Expand Up @@ -325,6 +330,11 @@ type SecretSource struct {
Secret volume sources are validated to ensure that the specified object reference actually points
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

A new Kubelet volume plugin will be added to handle volumes with a secret source. This plugin will
Expand Down Expand Up @@ -382,13 +392,14 @@ To create a pod that uses an ssh key stored as a secret, we first need to create
"kind": "Secret",
"id": "ssh-key-secret",
"data": {
"id_rsa.pub": "dmFsdWUtMQ0K",
"id_rsa": "dmFsdWUtMg0KDQo="
"id-rsa.pub": "dmFsdWUtMQ0K",
"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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

possible future improvement: optional AsciiArmor.

https://gist.github.com/jyap808/8250067


Now we can create a pod which references the secret with the ssh key and consumes it in a volume:

Expand Down Expand Up @@ -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:

/etc/secret-volume/id_rsa.pub
/etc/secret-volume/id_rsa
/etc/secret-volume/id-rsa.pub
/etc/secret-volume/id-rsa

The container is then free to use the secret data to establish an ssh connection.

Expand Down