Kubernetes is a popular open source tool for automating application development. While Kubernetes includes a basic solution for keeping secrets (passwords, tokens, or keys), most organizations need an extra layer of management and security to streamline development and protect against leaks. 

Let’s take a deeper look at what Kubernetes provides and how you can easily secure your Kubernetes secrets while keeping your development team agile.

How Kubernetes Manages Secrets

Just about every application deployed through Kubernetes needs privileged access to services and resources such as Pods and PersistentVolumes (PVs). Kubernetes Secrets are the native Kubernetes solution for storing digital authentication credentials so that you don’t have to hard code them in your applications.

By default, Kubernetes Secrets are stored as base-64 encoded strings in the Kubernetes API server’s underlying data store (etcd). Although the secrets are encoded, they are not encrypted, and can easily be decoded. In practice, anyone with access to your etcd cluster has access to your Kubernetes Secrets. In addition, etcd does not provide many of the administrative tools critical for managing sensitive data, such as audit logs and key rotation.

If you were setting up a new environment, you could overcome this vulnerability by not using Kubernetes Secrets at all, and instead of managing your secrets with another, more secure secrets management solution. This type of radical shift is impractical for existing environments because of just how extensively Kubernetes Secrets are used.

The challenge is to find an alternative solution that, on the one hand, enables your applications to continue consuming Kubernetes Secrets from the etcd database, while on the other hand, ensures that the secrets are securely encrypted. 

Essentially, you need to find an external Key Management System (KMS) for your Kubernetes Secrets. A KMS creates, manages, and stores encryption keys as a centralized service for clients dealing with sensitive data that must be protected. 

Using Akeyless as an external KMS for Kubernetes does exactly this, by applying an encryption mechanism called envelope encryption.

Envelope Encryption Explained

Envelope encryption is a method that encrypts your data with a data encryption key (DEK), and then encrypts that data encryption key with another key – a Key Encryption Key. This extra layer of encryption is also referred to as wrapping, hence the envelope analogy. 

Kubernetes uses a DEK to encrypt the secret. To protect this key while it’s stored, Akeyless uses another encryption key – the KEK – to encrypt the DEK. This KEK is defined and managed in the Akeyless Vaultless Platform, protected by Akeyless’s patented Distributed Fragments Cryptography (DFC™) technology, so that no entity outside of your organization – even Akeyless – has full access to the encryption key.

So How Does Akeyless Work as an External KMS?

Akeyless provides a plugin that enables it to function as an external KMS for Kubernetes. The Akeyless K8s External KMS plugin runs as a static pod or as a standalone docker container on each of the master nodes in your Kubernetes cluster, where it listens for requests from the Kubernetes API server.

Encrypting Kubernetes Secrets with Akeyless

When you create a new Kubernetes Secret to store credentials, the Kubernetes API server generates a unique DEK, and uses it to encrypt the secret. At the same time, the Akeyless K8s External KMS plugin running on your Kubernetes cluster sends the DEK to the Akeyless Vaultless Platform for encryption.

Akeyless encrypts the DEK using a dedicated KEK, and returns the encrypted DEK to the Akeyless K8s External KMS plugin. The plugin returns the encrypted DEK to the Kubernetes API server, which stores it in etcd together with the secret it encrypts. Note that the plaintext DEK is never stored on the disk.

Decrypting Kubernetes Secrets Encrypted by Akeyless

When an application requests a secret, the Kubernetes API server sends the encrypted DEK to Akeyless for decryption. Akeyless first authenticates the Kubernetes API server to verify that it is authorized to access the decrypted DEK. If so, Akeyless then uses the KEK to decrypt the DEK, and returns the value to the Kubernetes API server. The Kubernetes API server uses the plaintext of the DEK to decrypt the Kubernetes secret stored in etcd, and returns the decrypted secret to the application.

Scale, Simplify and Secure K8s Secrets with Akeyless

By using Akeyless Secrets Management, Kubernetes environments can simplify and scale their processes, no matter where they run. The Zero Knowledge platform ensures Akeyless customers maintain full custody of their keys. Additional benefits of our secrets management solution include:

• The Highest Levels of Encryption: Your keys are encrypted using Akeyless’ innovative Distributed Fragments Cryptography™, which is FIPS 140-2 certified.
• Granular Authentication and Authorization: The platform’s role-based access functionality ensures that only authenticated and authorized users can encrypt or decrypt the KEK.
• Comprehensive Auditing: For added peace of mind, every action within the system is tracked in the audit logs, giving you a detailed record of who is accessing your KEK, when, and from where.