In the contemporary corporate environment, Kubernetes (“k8s”) have emerged as a system used for deploying applications, to efficiently use the containerized infrastructure by which the apps are powered. Companies can choose to run Kubernetes both on-premises or within a public Cloud. Managed K8s solutions can be availed through cloud systems like Azure, GCP, and AWS which can enable companies to swiftly get started and operate Kubernetes apps efficiently.

Due to its abstraction of all underlying layers, DevOps around the industry are concerned about the security levels that a Kubernetes implementation can provide. There are various levels at which security protocols need to be implemented. One of them is safeguarding sensitive information, synonymously referred to as Secrets, in Kubernetes that application uses. Secrets can be in the form of tokens, passwords, usernames, endpoints, API id, etc. Here we are going to talk about a few ways you can safeguard some of this sensitive information with K8s setup.

Most of the Secrets are passed on as environment variables, so the first step to identify those environment variables is to identify what needs to be stored as Secrets e.g. there are variables which you need during a build (e.g. Commit Id), and some during deployment(e.g. Ports to open); few are required by an application to run(e.g. DB credentials). To identify which of these are actual candidates to be stored as Secrets.

Once secrets are identified, you can use the following ways to securely store and retrieve them from Kubernetes stack:

Kubernetes offer a built-in mechanism for securely storing configuration values or ‘secrets’ that a company would want to keep private. Just like any other declarations in K8s, a Secret can also be either defined in a YAML file using kubectl apply -f or it can be passed through the command line using kubectl create secret command.

Kubernetes allows these Secrets to be RBAC i.e. you can define which Namespaces, Service Accounts, and their contents are allowed to access certain Secrets. K8s store this data as base64 encoded(not encrypted). These Secrets can be accessed using environment variables(env tag in YAML) or as attached volumes for Containers.

Like any other information about the K8s cluster, these Secrets are also stored on the cluster’s etcd DB in plaintext. And since etcd doesn’t provide encryption by default, you’ve to be very careful while using K8s in-built Secret Management. However, there are ways you can secure data at rest and in transit using tricks like using external KMS(key management service), enabling TLS and ensuring that only the Kube master can access the secrets.

Hence, it is prudent that companies choose to use third-party solutions to protect their secret data. There are three broad categories of secrets management solutions in the case of Kubernetes. They are:

• Secrets management services from a certain cloud vendor.
• Open source solutions that are run by the internal company staff, either in the cluster or nearby.
• Proprietary solutions from a vendor.

Managed cloud solutions would be a good choice for companies who run their operations in one of the major public cloud systems and want swift services for secrets management. The common cloud secret services include:

• AWS Secrets Manager:

This service is a part of the Amazon Web Services and has been designed to help companies to protect access to their IT resources, applications, and services. This service enables companies to easily manage, rotate and retrieve API keys, database credentials, and various other secrets throughout their lifecycle.

• Cloud KMS:

This service allows companies to protect sensitive data in the Google Cloud Platform and efficiently manage cryptographic keys for their cloud services.

• Azure Key Vault:

This Microsoft developed tool helps in both storing and accessing secrets, including API keys, passwords, and certificates.

Vault and Sealed Secrets are two popular open-source secret managers that are commonly chosen by companies that do not avail managed K8s services through any cloud platform.

Vault
The HashiCorps’s Vault is among the most popular and feature-rich secret management solutions used in Kubernetes. It is known to have more features than the typical cloud-managed solutions and is extremely secure as well. It additionally works perfectly with GKW and EKS, and just about anywhere a business may run Kubernetes. Cloud solutions, however, are much easier to set up and configure than a performant HA Vault cluster.

The major advantageous features of Vault include:

1. Completely private Cubbyholes where the token bearer would be the only one able to access the data.
2. Vault can automatically create accounts and credentials for businesses in databases and cloud IAMs.
3. SSH certificate and PKI certificate would allow businesses to generate and store certificates with a single API call.
4. Cross-region/Cross-Cloud/Cross Datacenter replication facilitating support for filters to restrict data that should not be transferred across diverse clusters
5. Support for a host of authentication methods, as well as where MFA is required

Sealed Secrets
The Sealed Secrets is known to work by running a controller inside the K8s cluster of a company that takes a secret data and a public key, while subsequently providing an encrypted string that can be used inside the typical configuration files and would be only decrypted by the controller having the relevant private key. This secret management solution enables companies to store secret credentials in configuration files in Git directly, and subsequently share the Git repository with all who would require accessing it while making sure that none of them would have access to the given credentials.

Keys and passwords are among the most important and widely used tools that contemporary organizations have for authenticating applications and users. Hence, they must choose the perfect secret management solution as per their business requirements and objectives.