Move mounted Secrets sections verbatim to task page
Shannon Kularathna
parent
4dfacee24c
commit
b592215c13
|
|
@ -181,45 +181,6 @@ If you want to access data from a Secret in a Pod, one way to do that is to
|
|||
have Kubernetes make the value of that Secret be available as a file inside
|
||||
the filesystem of one or more of the Pod's containers.
|
||||
|
||||
To configure that, you:
|
||||
|
||||
1. Create a secret or use an existing one. Multiple Pods can reference the same secret.
|
||||
1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything,
|
||||
and have a `.spec.volumes[].secret.secretName` field equal to the name of the Secret object.
|
||||
1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the secret. Specify
|
||||
`.spec.containers[].volumeMounts[].readOnly = true` and
|
||||
`.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the
|
||||
secrets to appear.
|
||||
1. Modify your image or command line so that the program looks for files in that directory. Each
|
||||
key in the secret `data` map becomes the filename under `mountPath`.
|
||||
|
||||
This is an example of a Pod that mounts a Secret named `mysecret` in a volume:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: mypod
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: foo
|
||||
mountPath: "/etc/foo"
|
||||
readOnly: true
|
||||
volumes:
|
||||
- name: foo
|
||||
secret:
|
||||
secretName: mysecret
|
||||
optional: false # default setting; "mysecret" must exist
|
||||
```
|
||||
|
||||
Each Secret you want to use needs to be referred to in `.spec.volumes`.
|
||||
|
||||
If there are multiple containers in the Pod, then each container needs its
|
||||
own `volumeMounts` block, but only one `.spec.volumes` is needed per Secret.
|
||||
|
||||
{{< note >}}
|
||||
Versions of Kubernetes before v1.22 automatically created credentials for accessing
|
||||
the Kubernetes API. This older mechanism was based on creating token Secrets that
|
||||
|
|
@ -238,123 +199,6 @@ You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubec
|
|||
command to obtain a token from the `TokenRequest` API.
|
||||
{{< /note >}}
|
||||
|
||||
#### Projection of Secret keys to specific paths
|
||||
|
||||
You can also control the paths within the volume where Secret keys are projected.
|
||||
You can use the `.spec.volumes[].secret.items` field to change the target path of each key:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
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-group/my-username
|
||||
```
|
||||
|
||||
What will happen:
|
||||
|
||||
* the `username` key from `mysecret` is available to the container at the path
|
||||
`/etc/foo/my-group/my-username` instead of at `/etc/foo/username`.
|
||||
* the `password` key from that Secret object is not projected.
|
||||
|
||||
If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected.
|
||||
To consume all keys from the Secret, all of them must be listed in the `items` field.
|
||||
|
||||
If you list keys explicitly, then all listed keys must exist in the corresponding Secret.
|
||||
Otherwise, the volume is not created.
|
||||
|
||||
#### Secret files permissions
|
||||
|
||||
You can set the POSIX file access permission bits for a single Secret key.
|
||||
If you don't specify any permissions, `0644` is used by default.
|
||||
You can also set a default mode for the entire Secret volume and override per key if needed.
|
||||
|
||||
For example, you can specify a default mode like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: mypod
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: foo
|
||||
mountPath: "/etc/foo"
|
||||
volumes:
|
||||
- name: foo
|
||||
secret:
|
||||
secretName: mysecret
|
||||
defaultMode: 0400
|
||||
```
|
||||
|
||||
The secret is mounted on `/etc/foo`; all the files created by the
|
||||
secret volume mount have permission `0400`.
|
||||
|
||||
{{< note >}}
|
||||
If you're defining a Pod or a Pod template using JSON, beware that the JSON
|
||||
specification doesn't support octal notation. You can use the decimal value
|
||||
for the `defaultMode` (for example, 0400 in octal is 256 in decimal) instead.
|
||||
If you're writing YAML, you can write the `defaultMode` in octal.
|
||||
{{< /note >}}
|
||||
|
||||
#### Consuming Secret values from volumes
|
||||
|
||||
Inside the container that mounts a secret volume, the secret keys appear as
|
||||
files. The secret values are base64 decoded and stored inside these files.
|
||||
|
||||
This is the result of commands executed inside the container from the example above:
|
||||
|
||||
```shell
|
||||
ls /etc/foo/
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
username
|
||||
password
|
||||
```
|
||||
|
||||
```shell
|
||||
cat /etc/foo/username
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
admin
|
||||
```
|
||||
|
||||
```shell
|
||||
cat /etc/foo/password
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
The program in a container is responsible for reading the secret data from these
|
||||
files, as needed.
|
||||
|
||||
#### Mounted Secrets are updated automatically
|
||||
|
||||
When a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks
|
||||
|
|
|
|||
|
|
@ -149,6 +149,127 @@ Here is a configuration file you can use to create a Pod:
|
|||
39528$vdg7Jb
|
||||
```
|
||||
|
||||
Modify your image or command line so that the program looks for files in the
|
||||
`mountPath` directory. Each key in the Secret `data` map becomes a file name
|
||||
in this directory.
|
||||
|
||||
#### Projection of Secret keys to specific paths
|
||||
|
||||
You can also control the paths within the volume where Secret keys are projected.
|
||||
You can use the `.spec.volumes[].secret.items` field to change the target path of each key:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
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-group/my-username
|
||||
```
|
||||
|
||||
What will happen:
|
||||
|
||||
* the `username` key from `mysecret` is available to the container at the path
|
||||
`/etc/foo/my-group/my-username` instead of at `/etc/foo/username`.
|
||||
* the `password` key from that Secret object is not projected.
|
||||
|
||||
If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected.
|
||||
To consume all keys from the Secret, all of them must be listed in the `items` field.
|
||||
|
||||
If you list keys explicitly, then all listed keys must exist in the corresponding Secret.
|
||||
Otherwise, the volume is not created.
|
||||
|
||||
#### Secret files permissions
|
||||
|
||||
You can set the POSIX file access permission bits for a single Secret key.
|
||||
If you don't specify any permissions, `0644` is used by default.
|
||||
You can also set a default mode for the entire Secret volume and override per key if needed.
|
||||
|
||||
For example, you can specify a default mode like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: mypod
|
||||
spec:
|
||||
containers:
|
||||
- name: mypod
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: foo
|
||||
mountPath: "/etc/foo"
|
||||
volumes:
|
||||
- name: foo
|
||||
secret:
|
||||
secretName: mysecret
|
||||
defaultMode: 0400
|
||||
```
|
||||
|
||||
The secret is mounted on `/etc/foo`; all the files created by the
|
||||
secret volume mount have permission `0400`.
|
||||
|
||||
{{< note >}}
|
||||
If you're defining a Pod or a Pod template using JSON, beware that the JSON
|
||||
specification doesn't support octal notation. You can use the decimal value
|
||||
for the `defaultMode` (for example, 0400 in octal is 256 in decimal) instead.
|
||||
If you're writing YAML, you can write the `defaultMode` in octal.
|
||||
{{< /note >}}
|
||||
|
||||
#### Consuming Secret values from volumes
|
||||
|
||||
Inside the container that mounts a secret volume, the secret keys appear as
|
||||
files. The secret values are base64 decoded and stored inside these files.
|
||||
|
||||
This is the result of commands executed inside the container from the example above:
|
||||
|
||||
```shell
|
||||
ls /etc/foo/
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
username
|
||||
password
|
||||
```
|
||||
|
||||
```shell
|
||||
cat /etc/foo/username
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
admin
|
||||
```
|
||||
|
||||
```shell
|
||||
cat /etc/foo/password
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
1f2d1e2e67df
|
||||
```
|
||||
|
||||
The program in a container is responsible for reading the secret data from these
|
||||
files, as needed.
|
||||
|
||||
## Define container environment variables using Secret data
|
||||
|
||||
### Define a container environment variable with data from a single Secret
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ spec:
|
|||
# name must match the volume name below
|
||||
- name: secret-volume
|
||||
mountPath: /etc/secret-volume
|
||||
readOnly: true
|
||||
# The secret data is exposed to Containers in the Pod through a Volume.
|
||||
volumes:
|
||||
- name: secret-volume
|
||||
|
|
|
|||
Loading…
Reference in New Issue