## Kubernetes Secrets

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don't need to include confidential data in your application code.

Secrets are similar to ConfigMaps but are specifically intended to hold confidential data. Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods.

A Pod can use Secrets in three ways:

- As files in a volume mounted on one or more of its containers.

- As container environment variable.

- By the kubelet when pulling images for the Pod.

Kubernetes provides several built-in types for some common usage scenarios. These types vary in terms of the validations performed and the constraints Kubernetes imposes on them. Built-in types include `Opaque`, service account token Secrets, Docker config Secrets, basic authentication Secrets, SSH authentication Secrets, TLS Secrets, and bootstrap token Secrets.

Individual Secrets are limited to 1MiB in size. This is to discourage creation of very large Secrets that could exhaust the API server and kubelet memory. However, creation of many smaller Secrets could also exhaust memory.

By default, Kubernetes stores Secrets 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. For safe use, enable Encryption at Rest for Secrets and enable or configure RBAC rules that restrict reading and writing the Secret.