Tweak line wrapping in secret concept page
This PR wrapps the long lines found in the secret.md concept page.
This commit is contained in:
Qiming Teng
parent
5b084a3166
commit
28f831e7d6
|
|
@ -30,13 +30,17 @@ Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap
|
|||
but are specifically intended to hold confidential data.
|
||||
|
||||
{{< caution >}}
|
||||
Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd.
|
||||
Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.
|
||||
Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store
|
||||
(etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd.
|
||||
Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read
|
||||
any Secret in that namespace; this includes indirect access such as the ability to create a
|
||||
Deployment.
|
||||
|
||||
In order to safely use Secrets, take at least the following steps:
|
||||
|
||||
1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
|
||||
1. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) with least-privilege access to Secrets.
|
||||
1. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) with
|
||||
least-privilege access to Secrets.
|
||||
1. Restrict Secret access to specific containers.
|
||||
1. [Consider using external Secret store providers](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver).
|
||||
|
||||
|
|
@ -203,9 +207,14 @@ 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`.
|
||||
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:
|
||||
|
||||
|
|
@ -321,7 +330,6 @@ spec:
|
|||
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
|
||||
|
|
@ -383,8 +391,10 @@ automated Secret updates.
|
|||
|
||||
The kubelet keeps a cache of the current keys and values for the Secrets that are used in
|
||||
volumes for pods on that node.
|
||||
You can configure the way that the kubelet detects changes from the cached values. The `configMapAndSecretChangeDetectionStrategy` field in
|
||||
the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) controls which strategy the kubelet uses. The default strategy is `Watch`.
|
||||
You can configure the way that the kubelet detects changes from the cached values. The
|
||||
`configMapAndSecretChangeDetectionStrategy` field in the
|
||||
[kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) controls
|
||||
which strategy the kubelet uses. The default strategy is `Watch`.
|
||||
|
||||
Updates to Secrets can be either propagated by an API watch mechanism (the default), based on
|
||||
a cache with a defined time-to-live, or polled from the cluster API server on each kubelet
|
||||
|
|
@ -515,26 +525,26 @@ for more information about the `imagePullSecrets` field.
|
|||
The `imagePullSecrets` field is a list of references to secrets in the same namespace.
|
||||
You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry
|
||||
password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod.
|
||||
See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
|
||||
See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
for more information about the `imagePullSecrets` field.
|
||||
|
||||
##### Manually specifying an imagePullSecret
|
||||
|
||||
You can learn how to specify `imagePullSecrets` from the [container images](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
You can learn how to specify `imagePullSecrets` from the
|
||||
[container images](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
documentation.
|
||||
|
||||
##### Arranging for imagePullSecrets to be automatically attached
|
||||
|
||||
You can manually create `imagePullSecrets`, and reference these from
|
||||
a ServiceAccount. Any Pods created with that ServiceAccount
|
||||
or created with that ServiceAccount by default, will get their `imagePullSecrets`
|
||||
field set to that of the service account.
|
||||
You can manually create `imagePullSecrets`, and reference these from a ServiceAccount. Any Pods
|
||||
created with that ServiceAccount or created with that ServiceAccount by default, will get their
|
||||
`imagePullSecrets` field set to that of the service account.
|
||||
See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
|
||||
for a detailed explanation of that process.
|
||||
for a detailed explanation of that process.
|
||||
|
||||
### Using Secrets with static Pods {#restriction-static-pod}
|
||||
|
||||
You cannot use ConfigMaps or Secrets with
|
||||
{{< glossary_tooltip text="static Pods" term_id="static-pod" >}}.
|
||||
You cannot use ConfigMaps or Secrets with {{< glossary_tooltip text="static Pods" term_id="static-pod" >}}.
|
||||
|
||||
## Use cases
|
||||
|
||||
|
|
@ -557,7 +567,8 @@ Create the Secret:
|
|||
kubectl apply -f mysecret.yaml
|
||||
```
|
||||
|
||||
Use `envFrom` to define all of the Secret's data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
|
||||
Use `envFrom` to define all of the Secret's data as container environment variables. The key from
|
||||
the Secret becomes the environment variable name in the Pod.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -635,9 +646,8 @@ The container is then free to use the secret data to establish an SSH connection
|
|||
|
||||
### Use case: Pods with prod / test credentials
|
||||
|
||||
This example illustrates a Pod which consumes a secret containing production
|
||||
credentials and another Pod which consumes a secret with test environment
|
||||
credentials.
|
||||
This example illustrates a Pod which consumes a secret containing production credentials and
|
||||
another Pod which consumes a secret with test environment credentials.
|
||||
|
||||
You can create a `kustomization.yaml` with a `secretGenerator` field or run
|
||||
`kubectl create secret`.
|
||||
|
|
@ -665,7 +675,8 @@ secret "test-db-secret" created
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping.
|
||||
Special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your
|
||||
[shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping.
|
||||
|
||||
In most shells, the easiest way to escape the password is to surround it with single quotes (`'`).
|
||||
For example, if your actual password is `S!B\*d$zDsb=`, you should execute the command this way:
|
||||
|
|
@ -1053,8 +1064,7 @@ You can create an `Opaque` type for credentials used for basic authentication.
|
|||
However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other
|
||||
people to understand the purpose of your Secret, and sets a convention for what key names
|
||||
to expect.
|
||||
The Kubernetes API verifies that the required keys are set for a Secret
|
||||
of this type.
|
||||
The Kubernetes API verifies that the required keys are set for a Secret of this type.
|
||||
|
||||
### SSH authentication secrets
|
||||
|
||||
|
|
@ -1083,14 +1093,12 @@ You could instead create an `Opaque` type Secret for credentials used for SSH au
|
|||
However, using the defined and public Secret type (`kubernetes.io/ssh-auth`) helps other
|
||||
people to understand the purpose of your Secret, and sets a convention for what key names
|
||||
to expect.
|
||||
and the API server does verify if the required keys are provided in a Secret
|
||||
configuration.
|
||||
and the API server does verify if the required keys are provided in a Secret configuration.
|
||||
|
||||
{{< caution >}}
|
||||
SSH private keys do not establish trusted communication between an SSH client and
|
||||
host server on their own. A secondary means of establishing trust is needed to
|
||||
mitigate "man in the middle" attacks, such as a `known_hosts` file added to a
|
||||
ConfigMap.
|
||||
mitigate "man in the middle" attacks, such as a `known_hosts` file added to a ConfigMap.
|
||||
{{< /caution >}}
|
||||
|
||||
### TLS secrets
|
||||
|
|
@ -1235,6 +1243,7 @@ Preventing changes to the data of an existing Secret has the following benefits:
|
|||
### Marking a Secret as immutable {#secret-immutable-create}
|
||||
|
||||
You can create an immutable Secret by setting the `immutable` field to `true`. For example,
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
|
|
@ -1285,7 +1294,6 @@ Any containers that run with `privileged: true` on a node can access all
|
|||
Secrets used on that node.
|
||||
{{< /warning >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- For guidelines to manage and improve the security of your Secrets, refer to
|
||||
|
|
@ -1294,3 +1302,4 @@ Secrets used on that node.
|
|||
- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret`
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue