July 27, 2022
Posted by Miryam Brand
Since it was first launched in 2014, Kubernetes has been adopted almost universally as the container orchestration platform of choice. By automating many of the manual processes that were once required to deploy and scale applications, Kubernetes simply and reliably solves many common DevOps challenges, and has revolutionized the way we build and deliver applications by making it almost effortless to run workloads in containers at scale.
But is Kubernetes safe?
In order to provide this level of automation, components in Kubernetes environments use secrets such as credentials, API keys, tokens, and SSH certificates to communicate over trusted and secure connections. This presents a logistical dilemma. On the one hand, these secrets need to be available for containers to use, while on the other, they need to remain, well, secret.
The Kubernetes solution to this quandary comes in the form of Kubernetes Secrets, which are designed to store digital authentication credentials so that you don’t have to hard code them in your applications, pod definitions, or container images. By default, Kubernetes Secrets are stored as base-64 encoded strings in the Kubernetes API server’s underlying data store (etcd).
While this may sound like a reasonable solution, Kubernetes Secrets have two serious limitations.
- Kubernetes Secrets are not stored securely. Although Kubernetes Secrets are encoded, they are not encrypted, and can easily be decoded.
- etcd does not support administrative tools critical for managing secrets over time, such as secret revocation and auditing.
With the critical role secrets play in Kubernetes environments, it is highly recommended that you implement a more secure secrets management solution like Akeyless Secrets Orchestration to centrally manage and protect your Kubernetes secrets. Akeyless manages all stages of the secrets lifecycle, from creation to revocation, and securely stores the secrets using patented Distributed Fragments Cryptography™ (DFC) technology. Perhaps most importantly, Akeyless provides a Kubernetes plugin so that it is as effortless for containerized applications to use secrets sourced from the Akeyless platform as it is for them to use Kubernetes Secrets sourced from etcd. Let’s see how.
Securing Kubernetes with Akeyless: How does it work?
The Akeyless Kubernetes secrets injection plugin enables containerized applications to use secrets sourced from the Akeyless platform by leveraging the Kubernetes mutating admission webhook to listen for trigger events. When such an event occurs, the webhook injects an executable into the Kubernetes container. The executable then requests secrets from the Akeyless platform based on annotations in your pod deployment file.
The webhook can use one of two types of containers – init containers or sidecar containers.
- With init containers, the webhook looks for annotations that correspond to a specific schema. When the webhook finds these annotations, it adds the init container that authenticates to the Akeyless platform and pre-populates the secret into a pod as part of the pod lifecycle. Applications can then read the secret from the platform through environment variables.
- With sidecar containers, a second container runs alongside the init container. The benefit of this method is that it can refresh the secret at configurable intervals, and write the updated value to the destination file.
All of this is completely transparent to the applications that need to use these secrets. All they have to do is retrieve the value of the secret from a predefined filesystem path. To learn more about using Akeyless with Kubernetes, check out our walkthrough here.
Secret creation with Akeyless
While the secrets you store in the Akeyless platform can be static values, known as static secrets, we recommend that you use dynamic secrets in Akeyless to automatically generate secret values as needed.
Dynamic secrets are ephemeral, temporary credentials that are generated on-demand to provide a client with access to a resource for a limited period of time, with a limited set of permissions. With dynamic secrets, clients get access to a resource with the minimum privileges they need to accomplish a specific task, for the minimum time required. Especially for ephemeral machine-to-machine operations, this could be for just a few seconds.
So, in a workflow that uses dynamic secrets, when a Kubernetes container (client) spins up and requires access to a database, the container is given temporary credentials that are created on the spot and deleted automatically after a predefined amount of time. New credentials will be created when access is needed again by the client.
Revocation with Akeyless
When you create a dynamic secret in the Akeyless platform, you can configure it to automatically expire after a configurable period. You can also manually revoke both static and dynamic secret values directly from the Akeyless interface or CLI—for example, if you detect a security breach and want to limit access.
Auditing with Akeyless
The Akeyless platform records detailed audit logs of all secret access in the system, providing a complete track record of Akeyless system operations to enable administrators to examine suspicious activity and diagnose and troubleshoot issues. Akeyless integrates with multiple log management systems, such as Logz.io and Splunk, so that logs can be managed as part of your central event management solution.
The bottom line
Akeyless enables you to overcome the vulnerabilities inherent to Kubernetes Secrets by providing a comprehensive secrets management solution that centrally manages and protects your Kubernetes secrets. Akeyless seamlessly integrates with your Kubernetes clusters and enables you to manage and securely store your Kubernetes secrets without interrupting or slowing down the development life cycle.
Want to learn more about securing your Kubernetes platform with Akeyless? Get a demo today!
