Kubernetes Cluster Configuration Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 11: Line 11:


Secrets are consumed by applications, and they can be exposed to pods in two ways:
Secrets are consumed by applications, and they can be exposed to pods in two ways:
* As files in dedicated [[Kubernetes Storage Concepts#Volume|volumes]] mounted in the pod. When the pod deploys, each key/value entry of the secret's [[#Secret_Data_Map|data map]] is exposed as an individual file under the volume associated with the secret. The the file name is given by the key and the file content is filled with decoded value from the secret. For specific configuration details, see [[Kubernetes_Secrets_Operations#Consume_a_Secret_as_a_File|Consume a Secret as a File]]. By default, the keys are mapped as files in the volume root. However, specific keys can be mapped onto arbitrary relative paths in the volume, and the permissions under which the corresponding files are exposed can be configured. For more details, see [[Kubernetes_Secrets_Operations#Projection_of_Keys_to_Specific_Paths_with_Specific_Permissions|Projection of Keys to Specific Paths with Specific Permissions]]. Many files (key/value pairs) can be packaged into one secret, or many secrets can be used, whichever is most convenient.
* As files in dedicated [[Kubernetes Storage Concepts#Volume|volumes]] mounted in the pod. When the pod deploys, each key/value entry of the secret's [[#Secret_Data_Map|data map]] is exposed as an individual file under the volume associated with the secret. The the file name is given by the key and the file content is filled with decoded value from the secret. For specific configuration details, see [[Kubernetes_Secrets_Operations#Consume_a_Secret_as_a_File|Consume a Secret as a File]]. By default, each key is projected as a file in the volume root. However, specific keys can be mapped onto arbitrary relative paths in the volume, and the permissions under which the corresponding files are exposed can be configured. For more details, see [[Kubernetes_Secrets_Operations#Projection_of_Keys_to_Specific_Paths_with_Specific_Permissions|Projection of Keys to Specific Paths with Specific Permissions]]. Many files (key/value pairs) can be packaged into one secret, or many secrets can be used, whichever is most convenient.
* As [[Kubernetes_Pod_and_Container_Concepts#Environment_Variables|environment variables]] exposed to containers in the pod.  
* As [[Kubernetes_Pod_and_Container_Concepts#Environment_Variables|environment variables]] exposed to containers in the pod.  



Revision as of 00:43, 24 August 2019

Internal

Secrets

Secrets

A secret is a mechanism, backed by a Kubernetes API resource, that allows applications running on a Kubernetes cluster to safely manage, store and access security-sensitive information such as passwords, OAuth tokens and ssh keys. This mechanism provides a better alternative to placing that information in a container image or in the pod metadata. An individual secret contains a small amount of data, limited to 1 MiB - this is to discourage creation of very large secrets that would exhaust API server and kubelet memory. Entire multi-line configuration files can be exposed as secrets.

A Secret instance contains two maps: the data map, which is used to store arbitrary key/value pairs, where the values are base64-encoded string, and stringData map, which is a field provided for convenience that allows to provide secret data as unencoded fields. "stringData" field allows putting a non-base64 encoded string directly into the secret, and the string will be encoded by Kubernetes when the Secret is created or updated.

Secrets are consumed by applications, and they can be exposed to pods in two ways:

  • As files in dedicated volumes mounted in the pod. When the pod deploys, each key/value entry of the secret's data map is exposed as an individual file under the volume associated with the secret. The the file name is given by the key and the file content is filled with decoded value from the secret. For specific configuration details, see Consume a Secret as a File. By default, each key is projected as a file in the volume root. However, specific keys can be mapped onto arbitrary relative paths in the volume, and the permissions under which the corresponding files are exposed can be configured. For more details, see Projection of Keys to Specific Paths with Specific Permissions. Many files (key/value pairs) can be packaged into one secret, or many secrets can be used, whichever is most convenient.
  • As environment variables exposed to containers in the pod.

Multiple pods can reference the same secret. A pod must explicitly reference a secret in its manifest to access it. If that does not happen, the system will not initialize the infrastructure that exposes the information to the pod.

Secrets can also be used by other parts of the system, without being directly exposed to pods.

Secret Types

Opaque

kubernetes.io/service-account-token

Accessible on pods as /var/run/secrets/kubernetes.io/serviceaccount.

Secrets Operations

Secrets TODO