github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

clarification of how to access a secret from a pod

pull/6/head
Marek Biskup 2015-06-17 14:58:54 +02:00 committed by marekbiskup
parent 483ba4e9eb
commit 11a76c69ae
1 changed files with 22 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/secrets.md
View File

@ -22,14 +22,16 @@ This is an example of a simple secret, in json format:
}, },
"data": { "data": {
"username": "dmFsdWUtMQ0K", "username": "dmFsdWUtMQ0K",
"password": "dmFsdWUtMg0KDQo=" "password": "dmFsdWUtMg0K"
} }
} }
``` ```
The data field is a map. Its keys must match The data field is a map. Its keys must match
[DNS_SUBDOMAIN](design/identifiers.md), except that leading dots are also [DNS_SUBDOMAIN](design/identifiers.md), except that leading dots are also
allowed. The values are arbitrary data, encoded using base64. allowed. The values are arbitrary data, encoded using base64. The values of
username and password in the example above, before base64 encoding,
are `value-1` and `value-2`, respectively, with carriage return and newline characters at the end.
This is an example of a pod that uses a secret, in json format: This is an example of a pod that uses a secret, in json format:
```json ```json
@ -81,6 +83,21 @@ not common ways to create pods.)
### Consuming Secret Values ### Consuming Secret Values
Inside the container that mounts a secret volume, the secret keys appear as
files and the secret values are base-64 decoded and stored inside these files.
This is the result of commands
executed inside the container from the example above:
```
$ ls /etc/foo/
username
password
$ cat /etc/foo/username
value-1
$ cat /etc/foo/password
value-2
```
The program in a container is responsible for reading the secret(s) from the The program in a container is responsible for reading the secret(s) from the
files. Currently, if a program expects a secret to be stored in an environment files. Currently, if a program expects a secret to be stored in an environment
variable, then the user needs to modify the image to populate the environment variable, then the user needs to modify the image to populate the environment
@ -107,7 +124,8 @@ the original pod must be deleted, and a new pod (perhaps with an identical
workflow as deploying a new container image. The `kubectl rolling-update` workflow as deploying a new container image. The `kubectl rolling-update`
command can be used ([man page](kubectl_rolling-update.md)). command can be used ([man page](kubectl_rolling-update.md)).
The `resourceVersion` of the secret is not specified when it is referenced. The [`resourceVersion`](api-conventions.md#concurrency-control-and-consistency)
of the secret is not specified when it is referenced.
Therefore, if a secret is updated at about the same time as pods are starting, Therefore, if a secret is updated at about the same time as pods are starting,
then it is not defined which version of the secret will be used for the pod. It then it is not defined which version of the secret will be used for the pod. It
is not possible currently to check what resource version of a secret object was is not possible currently to check what resource version of a secret object was