Pre-requisite:- Kubernetes
Kubernetes is an open-source container orchestration system mainly used for automated software deployment, management, and scaling. Kubernetes is also known as K8s. Kubernetes was originally developed by Google but it is now being maintained by Cloud Native Computing Foundation. It was originally designed to be interfaced with only Docker runtime but it now works with containers and CRI-O also. The main purpose of Kubernetes is to automate the operational tasks of container management. It is included with built-in commands for the deployment of applications and rolling out the required changes in the application. It is currently being used by companies like Google, Spotify, and capital one.
Secrets:
A secret in Kubernetes can be defined as an object that contains a small quantity of sensitive data like a password, a token, or a key. It contains information that is otherwise stored in a container image or pod specification. The main advantage of a secret is that we will not have to include sensitive or confidential data in the application code. There is less risk of losing or exposing secrete during the workflow of creating viewing, and editing Pods because they can be and are created independently of the pods in which they are being used. Secretes can be considered similar to ConfigMaps but the main difference between them is that they are specially designed to store and hold confidential data.
Uses of Secretes:
- Secrets can be used as a container environment variable.
- As a file in a volume mounted on at least one of its containers.
- It can be used by Kubelet when pulling images from the pod.
- Secretes are also used by the Kubernetes control plane.
Using a Secret:
- Secretes can be exposed as environment variables to be used by a container in a Pod or can be mounted as data volumes. It can even be used directly by other parts of the system without being directly exposed to the pods. If we consider an example a secret can store credentials that other parts of the system should use to interact with the external systems at the pace ourselves.
- The secret volume sources are validated to ensure that the specific object’s reference actually points to an object of a particular object of secret type. Due to this, the secrete should be created before any pods that depend on it. If the required secrete cannot be fetched due to its non-existence or due to the temporary lack of connection to the AOI server the kubelet periodically retires running that specific Pod. Kubelet also reports the event for that Pod including all the details of the problems fetching the secret.
- When we are defining a container environment variable based on a Secret we can make it optional. The default setting is that a secrete is required. None of the Pod Containers will start working until all the non-optional Secrete are available. That means if a pod references a specific key in a Secrete and it exists but it is missing the name key then the pod fails startup.
Alternatives to Secrets:
If there is a need to protect your data then Secrete is not the only option available. There are some other alternatives available.
- We can use ServiceAccount and its tokens to identify the cluster if the cloud native component has the need for authentication to another application that is also running within the same Kubernetes Cluster.
- We can use third-party tools that can be run by us either outside or from within the cluster that provides secrets management.
- If we need authentication we can implement a custom signer for X.509 certificates and then use CertificateSigningRequests to let that custom signer issue certificates to Pods that required them.
- We can use a device plugin to expose node local encryption hardware to a specific Pod.
There is no compulsion to use only services or one of these options. We can even combine two or more options based on our requirements.