Securing a Distributed Platform — Kubernetes Secret Management!

Today enterprises are already considering Kubernetes into their Microservice Architecture to orchestrate their containerized modern applications. With this massive digital transformation enterprises are watchfully working on multi-layer security to keep their distributed clusters secure.

Image Source: kublr.com

Kubernetes offers built-in security capabilities. A “secret” in Kubernetes is a means of storing sensitive information, like an OAuth token or SSH key, so that it’s accessible when necessary to pods in your cluster but protected from unnecessary visibility that could create security risks.

What is a Kubernetes Secret?

Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image. A secret is an object that contains small amount of sensitive data such as password, user name, token etc. rather than putting these sensitive information in POD or embedded into image, it is recommended to put the same into a separate file called as secret into base 64 encode format.

Secrets could be thought of as a relative of the least privilege principle, except instead of focusing on limiting the access of individual users to that which they actually do to get their work done, they focus on giving your applications the data they need to properly function without giving them (and the people that manage them) unfettered access to that data.

Another important feature is the ability to inject configuration options, secrets, and credentials into containers:

· Config Maps: a set of values that can be mapped to a pod as “volume” (to access all config map items as files) or passed as environment variables.

· Secrets: similar to config maps, secrets can be mounted into a pod as a volume to expose needed information or can be injected as environment variables. Secrets are intended to store credentials to other services that a container might need or to store any sensitive information.

Kubernetes Secrets defined, three ways:

To have better understanding, let’s run it through different scenarios which secrets make sense:

1) When you are running your application in Kubernetes and application needs credentials: when an enterprise deploy an application to Kubernetes, its sole purpose is to interact or orchestrate with other applications and different infrastructure components in order to serve efficiently to end customers. Now, when an application needs to interact with other services, components it needs an access controls. Rather than directly embedding the credentials access into the application configurations, kubernetes empowers to take advantage of Out of the Box secret capabilities where one can store security properties such as user name, Passwords, tokens into Base 64 encoded formats and application can élite values by refereeing the secret configuration file name.

For example, to store two strings in a Secret using the data field, convert the strings to base64 as follows:

echo -n 'admin' | base64

The output is similar to:

YWvxdtaW4=
echo -n '1f2d1es2e67df' | base64

The output is similar to:

MWYyZDFlMZPasU2N2Rm

Last step to create secret YAML file:

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWvxdtaW4=
password: MWYyZDFlMZPasU2N2Rm

Apply created mysecret.yaml file

kubectl apply -f ./secret.yaml

1) Kubernetes Secrets provide a means to protect sensitive information in a way that limits accidental exposure and provides flexibility: Secrets are only accessible to Pods if they are explicitly part of a mounted volume or at the time when the Kubelet is pulling the image to be used for the Pod. This prevents the need to store sensitive information in a Pod image, which mitigates the risk that data is compromised and makes it easier to vary things like credentials, cryptographic keys, etc. for different pods.

2) Kubernetes Secrets are a way to store and distribute sensitive information: think passwords, or an SSL certificate — that are used by applications in your Kubernetes cluster. Importantly, the declarative nature of Kubernetes definitions allows third-party solutions to be integrated with the Secret management

Conclusion

Not all configuration information is safe to keep out in the “public” and many if not most Kubernetes hosted workloads need usernames/passwords, tokens, keys or other private information to securely connect to other services. Kubernetes provides”secret” a built in mechanism for storing configuration values that you would prefer to keep private. They can be access controlled to specific namespaces, and their contents are not shown by default in kubectl get or describe output. They are base64 encoded.