In this blog we will learn about secrets management in Kubernetes. This will be a descriptive blog and it will be followed by a practical implementation of sealed secrets in the upcoming blog. We will know how sealed secrets will help us follow the Gitops approach where secret manifests can be safely stored in a GitHub repository post encryption.
What is Kubernetes?
Kubernetes is an open-source container orchestration engine for automating deployment, scaling, and managing containerized applications. The open-source project is hosted by the Cloud Native Computing Foundation. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates declarative configuration and automation. It has a large, rapidly growing ecosystem. There are many resources or objects used in Kubernetes.
Secrets in Kubernetes
Secrets in Kubernetes are the resource that manages the deployment of sensitive information, such as passwords, OAuth tokens, and SSH keys. It is suggested to store the sensitive information as a secret resource rather than having it imbibed in an environment variable. Secrets can be mounted as data volumes or exposed as environment variables to the containers in a Kubernetes Pod. Secrets in k8s are stored in a centralized repository named etcd in a base64 encoded format.
Problems with secrets in Kubernetes
The data in a Secret is obfuscated by using merely Base64 encoding. This encoding method does not encrypt the data within it.
Storing such files in a Git repository is highly insecure as it is easy to decode the Base64-encoded data. Anyone can accidentally commit the manifest files into the Git repositories, thus exposing sensitive information, such as credentials, tokens, or ssh keys.
Applications may also tend to expose the secrets in audit logs and monitoring systems.
Suggestions for secret management
We can follow these steps to safely use the secrets in Kubernetes:
- Enable Encryption at Rest
- Enable or configure RBAC rules to restrict access to the secrets in a cluster
- Restrict Secret access to specific containers, or the containers that require access to the secret to perform their operations.
- Consider using external Secret store providers
What are sealed secrets?
Sealed Secrets are the resource in Kubernetes that are basically encrypted Secrets that can be created by anyone, but can only be decrypted by the controller running in the target cluster. The Sealed Secret is safe to share publicly and upload to git repositories. Once the Sealed Secret is safely uploaded to the target Kubernetes cluster, the sealed secrets controller will decrypt it and recover the original Secret.
Why to use sealed secrets?
If we follow the Gitops approach, there should be a single source of truth, which means all the manifests, configuration files, and deployment YAMLs should be present in the same repository. We cannot store sensitive information like passwords or secret tokens in a GitHub repository. This is a huge risk because the original sensitive credentials and values can easily be derived from the base64 encoding format.
Components of Sealed Secrets
Sealed secrets are comprised of these three components for their functionality:
- A controller deployed to the cluster
- A CLI tool called kubeseal
- A customer resource definition called Sealed Secret
Controller: It is responsible for managing the sealed secret deployment. The primary task of the controller is to manage the private and public keys for encryption and decryption purposes.
Kubeseal: It is a CLI tool that creates a CRD for sealed secrets from a secret. It communicates with the controller and retrieves the public key needed for encrypting the secrets.
CRD: It is a custom resource definition that we can apply in our Kubernetes cluster to create a secret.
How to use Sealed Secrets?
The controller generates a 4096-bit RSA key pair. The private key is stored in the form of a secret whereas the public key is made public to encrypt the secret.
Kubeseal uses this public key from the controller to seal the secret values.
The value is symmetrically encrypted using AES-256 with a randomly generated session key.
The session key is asymmetrically encrypted with the controller’s public key using SHA256.
Kubeseal creates a CRD for a sealed secret that can be safely pushed to the repository.
When the CRD Is applied in the cluster, the controller unseals it using the private key and creates a secret resource in the defined namespace.
Hey, readers! Thank you for sticking up till the end. If you have any questions/feedbacks regarding this blog, I am reachable at vidushi.bansal@knoldus.com. You can find more of my blogs here.
