What is a Secret?
A Kubernetes Secret is an object that enables us to store and manage sensitive information. A Secret can contain data like SSH keys, OAuth data, or other user authentication information like passwords. It is typically stored within a cluster in a manner native to Kubernetes. Using a Secret object provides more granular control over how highly sensitive data is used. It also lowers the risk of data exposure to unauthorized parties.
By default, anyone with access to the API or etcd (the underlying data store) in Kubernetes can view Secrets. When we create a Secrets resource, the API server stores the data in etcd in a base64 encoded form. Base64 is NOT encryption! To safely use Secrets, adjusting the minimum recommended values right away.
- Enable "Encryption at Rest" for Secrets.
- Quickly Enable or reconfigure RBAC rules that restrict the reading and writing of the Secret. Be aware that secrets can be obtained implicitly by anyone with permission to create a pod.
Why Should Secrets be Protected?
Typically, Kubernetes is insecure by default. All pods use CAP_NET_RAW permission levels. The ability to inject raw packets into the network, which is allowed by default, is a useful and efficient tool to accomplish specific start-up tasks. However, as all pods can open raw sockets, it is highly discouraged to enable this status after configuration.
Permitting these default settings to remain longer than necessary allows an attacker the ability to take over a single pod, possibly injecting malicious packets into the entire Kubernetes cluster. The initial permission level of secrets should be used quickly and then modified to lock down the system.
A quick etcd search reveals thousands of publicly accessible etcd servers, highlighting the need for increased security. etcd is an open-source, distributed, key-value store used to house and manage configuration data, state data, and metadata for Kubernetes.
How Do Secrets Work?
Secrets can be mounted as a volume or exposed as an environment variable to containers within a Kubernetes Pod. There are two types of secrets:
- Built-in secrets: Kubernetes service accounts automatically create secrets and attach them to containers using API credentials. This method can be overridden or disabled if additional security concerns are raised.
- Custom secrets: This is where we can define our sensitive or private data and create a Secret to store it.
These secrets can be placed in YAML files or other designated locations and are called upon to verify access, ascertain permission levels, or used for additional verification purposes.
How to Protect Secrets
We begin the process of protecting secrets by assuming a compromise will occur. This concept is one of the basic tenets of zero-trust security. Furthermore, we should employ TLS encryption for all in-transit Secrets. This encoding should occur at the application layer.
Changing Secrets regularly, just like passwords, is also an excellent practice to follow. Using isolation to keep secrets separate from all other objects only reduces the attack plane further. Lastly, employing reliable auditing practices across all access portals, logs, and other service gateways increases security. These steps provide a more granular security control process that will protect your secrets.
Three methods used to gain access to our secrets can be classified as follows:
- Outright Attacks: Hackers, intruders, or other infiltrators often scan or engineer their way into a cluster to gain information.
- Unintended Exposure: Secrets can get accidentally leaked from files stored in buckets or located in a repository.
- Misconfigured Permissions: Security issues occur if a permission setting is left too low or a group user is granted extra permissions.
Envelope encryption is a method used by Kubernetes to encrypt a key utilizing another key. It sits between the Kubernetes API and the etcd server and encrypts data that passes through it, so no unencrypted information is stored on etcd. Kubernetes 1.7 incorporates this feature into the core Kubernetes system.
Another tool used by Kubernetes is sealed secrets. Sealed Secrets is an open-source tool used for managing the deployment of sensitive information to Kubernetes clusters. It also stores secrets securely in a Git repository, which allows for integration into the CI/CD pipeline.
Creating a Secret
We can create a Secret object using one of the following methods.
We can use the kubectl create secret command. Here is the format to create a Secret.
root@host [~]# kubectl create secret (type) (name) (data)
- Type: The type is defined as a generic, TLS, or docker-registry element.
- Name: This is the name of the Secret.
- Data: This is a directory path or a key-value pair.
We can create secrets by hand in several ways. We can add the Secret information to a JSON or YAML file and use the kubectl apply command. This call defines the object contained within the file as being Secret. The object is then deployed using the following command.
root@host [~]# kubectl create -f filename.yaml
Additionally, a Secret can be generated from one or more files using the following flags --from-file or --from-env-file. When creating a Secret using the --from-file flag, the file's entire contents are the Secret itself. If the value of a Secret contains several key-value pairs, we use the --from-env-file flag instead. Using these flags, we can pass a single file or multiple files.
root@host [~]# kubectl create secret type name --from-file /path/to/file --from-file /path/to/file2
A directory that contains multiple files can be used by following this format.
root@host [~]# kubectl create secret type name --from-file /path/to/directory.
The following command creates a Secret using two files (user.txt and pass.txt), respectively. The following command sets the keys from data within those files.
root@host [~]# kubectl create secret generic authme --from-file ./user.txt --from-file ./pass.txt
Lastly, we can create Secrets using Kustomize. This tool is a standalone method used to customize objects in Kubernetes via a kustomization file. It lets users customize a raw YAML file while leaving the original YAML file undisturbed.
Editing a Secret
A current Secret can be edited using the following command.
root@host [~]#kubectl edit secrets authme
This command opens the default config editor, which allows us to update the base64 encoded Secret parameters contained within the data field.
To employ a Secret, a Pod requires a reference to the Secret. A Pod uses secrets in three ways:
- As a mounted volume that contains the files or resides on one or more containers.
- As an environment variable for a container.
- When pulling images for the Pod using the kubelet.
Different parts of the system can also use secrets without being directly exposed to the Pod. The full description of how secrets can be used would fill another article, so we end here.
Secrets are objects which contain sensitive data like passwords, SSH keys, or OAuth tokens. Storing this confidential information in a Secret is much safer and, to a greater extent, a more flexible method than storing it in the definition of a Pod or within a container image. Keeping our cluster safe and secure is the primary goal of using Secrets while allowing ease of access to those users and services which require access.
Our Solutions Team is filled with knowledgeable and experienced hosting advisors who have intimate knowledge of the technologies discussed in this article. Should you have any questions regarding this information, we will always answer any inquiries related to this article, 24 hours a day, 7 days a week, 365 days a year.
We will explain how you can take advantage of these platforms using either our Managed Cloud or Private Cloud Powered by VMware and NetApp! If you are on a Fully Managed VPS server, Cloud Dedicated, Private Parent server, or a Dedicated server owner and want to make a change to one of these platforms, give us a call at 800.580.4985, or open a chat or ticket with us to find out how!
Our Sales and Support teams are available 24 hours by phone or e-mail to assist.