Secrets - Kubernetes - 0 views
-
Putting this information in a secret is safer and more flexible than putting it verbatim in a PodThe smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. definition or in a container imageStored instance of a container that holds a set of software needed to run an application. .
-
A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key.
-
Users can create secrets, and the system also creates some secrets.
- ...63 more annotations...
-
To use a secret, a pod needs to reference the secret.
-
A secret can be used with a pod in two ways: as files in a volumeA directory containing data, accessible to the containers in a pod. mounted on one or more of its containers, or used by kubelet when pulling images for the pod.
-
--from-file
-
You can also create a Secret in a file first, in json or yaml format, and then create that object.
-
The Secret contains two maps: data and stringData.
-
The data field is used to store arbitrary data, encoded using base64.
-
Kubernetes automatically creates secrets which contain credentials for accessing the API and it automatically modifies your pods to use this type of secret.
-
kubectl get and kubectl describe avoid showing the contents of a secret by default.
-
stringData field is provided for convenience, and allows you to provide secret data as unencoded strings.
-
where you are deploying an application that uses a Secret to store a configuration file, and you want to populate parts of that configuration file during your deployment process.
-
a field is specified in both data and stringData, the value from stringData is used.
-
The keys of data and stringData must consist of alphanumeric characters, ‘-’, ‘_’ or ‘.’.
-
Newlines are not valid within these strings and must be omitted.
-
When using the base64 utility on Darwin/macOS users should avoid using the -b option to split long lines.
-
create a Secret from generators and then apply it to create the object on the Apiserver.
-
The generated Secrets name has a suffix appended by hashing the contents.
-
base64 --decode
-
Secrets can be mounted as data volumes or be exposed as environment variablesContainer environment variables are name=value pairs that provide useful information into containers running in a Pod. to be used by a container in a pod.
-
Multiple pods can reference the same secret.
-
Each key in the secret data map becomes the filename under mountPath
-
each container needs its own volumeMounts block, but only one .spec.volumes is needed per secret
-
use .spec.volumes[].secret.items field to change target path of each key:
-
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.
-
You can also specify the permission mode bits files part of a secret will have. If you don’t specify any, 0644 is used by default.
-
JSON spec doesn’t support octal notation, so use the value 256 for 0400 permissions.
-
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.
-
Mounted Secrets are updated automatically
-
Kubelet is checking whether the mounted secret is fresh on every periodic sync.
-
cache propagation delay depends on the chosen cache type
-
A container using a Secret as a subPath volume mount will not receive Secret updates.
-
Multiple pods can reference the same secret.
-
env: - name: SECRET_USERNAME valueFrom: secretKeyRef: name: mysecret key: username
-
Inside a container that consumes a secret in an environment variables, the secret keys appear as normal environment variables containing the base-64 decoded values of the secret data.
-
An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry password to the Kubelet so it can pull a private image on behalf of your Pod.
-
a secret needs to be created before any pods that depend on it.
-
Secret API objects reside in a namespaceAn abstraction used by Kubernetes to support multiple virtual clusters on the same physical cluster. . They can only be referenced by pods in that same namespace.
-
Individual secrets are limited to 1MiB in size.
-
Kubelet only supports use of secrets for Pods it gets from the API server.
-
Secrets must be created before they are consumed in pods as environment variables unless they are marked as optional.
-
References to Secrets that do not exist will prevent the pod from starting.
-
References via secretKeyRef to keys that do not exist in a named Secret will prevent the pod from starting.
-
Once a pod is scheduled, the kubelet will try to fetch the secret value.
-
Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret.
-
volumes: - name: secret-volume secret: secretName: ssh-key-secret
-
Special characters such as $, \*, and ! require escaping. If the password you are using has special characters, you need to escape them using the \\ character.
-
You do not need to escape special characters in passwords from files
-
make that key begin with a dot
-
Dotfiles in secret volume
-
.secret-file
-
a frontend container which handles user interaction and business logic, but which cannot see the private key;
-
a signer container that can see the private key, and responds to simple signing requests from the frontend
-
When deploying applications that interact with the secrets API, access should be limited using authorization policies such as RBAC
-
watch and list requests for secrets within a namespace are extremely powerful capabilities and should be avoided
-
watch and list all secrets in a cluster should be reserved for only the most privileged, system-level components.
-
additional precautions with secret objects, such as avoiding writing them to disk where possible.
-
A secret is only sent to a node if a pod on that node requires it
-
only the secrets that a pod requests are potentially visible within its containers
-
each container in a pod has to request the secret volume in its volumeMounts for it to be visible within the container.
-
In the API server secret data is stored in etcdConsistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.
-
limit access to etcd to admin users
-
Base64 encoding is not an encryption method and is considered the same as plain text.
-
A user who can create a pod that uses a secret can also see the value of that secret.
-
anyone with root on any node can read any secret from the apiserver, by impersonating the kubelet.
