avatarMaryam Tavakkoli

Summary

The website content provides a comparative analysis of three Kubernetes secret management solutions: External Secret Operator (ESO), Secret Store CSI Driver (SSCD), and Azure Key Vault to Kubernetes (AKV2K8S), highlighting their features, security approaches, and suitability for different use cases.

Abstract

The article delves into the realm of Kubernetes secret management, comparing three open-source projects designed to integrate external secret management systems with Kubernetes clusters. External Secret Operator (ESO) is noted for its broad provider support and efficient resource usage, operating as a deployment with a single replica by default. It syncs external secrets into Kubernetes secrets but lacks direct Pod injection, which is a security consideration. The Secret Store CSI Driver (SSCD) stands out for its ability to mount secrets as volumes directly into Pods, enhancing security over ESO. However, it operates as a daemonset, potentially consuming more resources, and has recently introduced alpha support for secret rotation. Azure Key Vault to Kubernetes (AKV2K8S) is tailored specifically for Azure Key Vault integration, offering both a controller for syncing secrets as native Kubernetes secrets and an injector for direct Pod environment variable injection, balancing security and resource efficiency. The article aims to assist in selecting the most appropriate secret management solution based on specific project requirements, considering factors such as security, resource efficiency, and support for disconnected scenarios.

Opinions

  • The author has a preference for solutions that offer direct injection of secrets into Pods, considering it more secure than syncing with Kubernetes secrets.
  • ESO is praised for its acceptance into the CNCF and its frequent release cycle, indicating active development and community support.
  • SSCD's recent introduction of secret rotation is seen as a positive step towards feature parity with other solutions, although it is still in alpha.
  • The author notes the importance of resource efficiency, favoring solutions like ESO and AKV2K8S that operate as deployments rather than SSCD, which operates as a daemonset and could lead to increased resource consumption.
  • The article suggests that AKV2K8S's dual-component approach (controller and injector) provides flexibility in secret management, catering to different security and operational needs within Kubernetes.
  • The author emphasizes the significance of being able to function in disconnected scenarios, where ESO has an advantage due to its use of native Kubernetes secrets.
  • The comparison of these tools indicates a nuanced understanding of the trade-offs between security, resource usage, and operational flexibility, with the recommendation that the choice of tool should align with the specific requirements of the project at hand.

Exploring Kubernetes Secret Management Solutions: A Comparative of External Secret Operator (ESO), Secret Store CSI Driver (SSCD), and Azure Key Vault to Kubernetes (AKV2K8S)

Photo by Shopify Photos from Burst

External Secret Operator (ESO), Secret Store CSI Driver (SSCD), and Azure Key Vault to Kubernetes (AKV2K8S) are all open-source projects that aim to provide secure and reliable secret management solutions for Kubernetes clusters.

All three projects rely on external secret management systems such as Azure Key Vault (AKV) for storing secrets. Then, they sync and map the secrets from such external systems to the applications running in Kubernetes.

While all three projects serve the same general purpose, some differences may make one more suitable for a particular use case than the others. Recently, I’ve been trying to find the best match for our project, and it took me a while to understand all the features, similarities, and differences of these three. Here, in this article, I tried to summarize my findings regarding that.

External Secret Operator (ESO)

From the External Secrets Operator Github page:

External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, IBM Cloud Secrets Manager, Akeyless, CyberArk Conjur and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.

External Secret Operator

Features and technical details

  • ESO documentation can be found HERE.
  • ESO was accepted to CNCF on July 26, 2022, and is at the Sandbox project maturity level.
  • ESO can be installed with a Helm chart
  • Supports different providers including Azure, AWS, HashiCorp Vault, GCP, IBM, CyberArc Conjur, and many more.
  • Exposing secrets to applications: ESO syncs external secrets into Kubernetes secrets, exclusively using this method.
  • Security: ESO lacks the ability to directly inject secrets into Pods. Due to this limitation, its security level is lower when compared to SSCS or akv2k8s injector, which offer more secure approaches.
  • ESO operates as a Deployment: with a replica count of 1 by default. Hence, it is resource efficient compared to SSCD which operates as a daemonset.
  • Secret rotation: ESO supports the auto-rotation of secrets with customizable sync intervals per secret. In other words, it updates the Kubernetes secret in case the secret was updated in the external secret store and the interval to do so is configurable.
  • Namespace and cluster-wide CRDs: Within ESO, its components are divided into distinct Custom Resource Definitions (CRDs) for both namespaces (ExternalSecret, SecretStore) and for the entire cluster (ClusterSecretStore, ClusterExternalSecret). This segregation contributes to a more organized and manageable syncing process.
  • Disconnected scenario: Since ESO utilizes native Kubernetes secrets, the cluster’s state of being offline does not pose any implications for tasks like restarting or scaling pods.
  • Contribution and releases: The ESO project currently has 248 contributors. The release intervals seem to be either monthly or every three weeks.

Secret Store CSI Driver (SSCD)

From the Secrets Store CSI Driver Github page:

Secrets Store CSI Driver for Kubernetes secrets — Integrates secrets stores with Kubernetes via a Container Storage Interface (CSI) volume. The Secrets Store CSI Driver is a subproject of Kubernetes SIG Auth.

The Secrets Store CSI Driver [secrets-store.csi.k8s.io](<http://secrets-store.csi.k8s.io>) allows Kubernetes to mount multiple secrets, keys, and certs stored in enterprise-grade external secrets stores into their pods as a volume. Once the Volume is attached, the data in it is mounted into the container's file system.

Secret Store CSI Driver

Features and technical details

  • SSCD documentation can be found HERE
  • SSCD can be installed with a Helm chart
  • Supports Linux and Windows containers
  • Supports different providers including Azure, AWS, HashiCorp Vault, and GCP
  • Supports mounting multiple secrets as a single volume
  • Exposing secrets to applications: SSCD mounts the external secret (from external secret management systems) as a volume in a pod directly. What’s more, once these volumes are set up and secrets are synchronized within them, SSCD can also be configured to generate Kubernetes secrets and store them within the cluster.
  • Security: SSCD directly mounts secrets to Pod volumes and due to that is more secure compared to ESO, which only supports syncing with Kubernetes secrets.
  • For the “Sync With Kubernetes Secrets” feature to function: A volume mount becomes necessary and must exist. In other words, if you do not want the volume mounting approach and only are expecting to sync an external secret with a Kubernetes secret, this cannot be achieved with the SSCD project. To enable Kubernetes secret sync feature, set this helm parameter: syncSecret.enabled=true.
  • SSCD operates as a Daemonset: leading to the deployment of a Pod on every node within the cluster. This can increase resource consumption due to the higher number of Pods. Additionally, its utilization of volumes contributes to the overall resource usage.
  • Secret rotation: To sync the volume mount and Kubernetes secret in case the secret was updated in the external secret store, was not supported until v0.0.15 and now is in alpha. So, it could be enabled explicitly by setting this helm parameter: enableSecretRotation=true. Also, the interval for secret rotation is configurable per cluster. Read more about the feature HERE.
  • Disconnecting scenario: When the cluster is offline, SSCD encounters difficulties in retrieving secrets, leading to mounting volume failures. Consequently, during periods of offline operation, scaling and restarting pods become unfeasible.
  • Contribution and releases: The SSCD project currently has 73 contributors. The release intervals seem to be either monthly or every other month.

Azure Key Vault to Kubernetes (AKV2K8S)

From the Azure Key Vault to Kubernetes Github page:

Azure Key Vault to Kubernetes (akv2k8s) makes Azure Key Vault secrets, certificates and keys available to your applications in Kubernetes, in a simple and secure way.

AKV2K8S

Features and technical details

  • AKV2k8s documentation can be found HERE
  • AKV2k8s can be installed with a Helm chart
  • This project has been developed explicitly to support secret syncing with the Azure key vault, and it does not support other providers.
  • Exposing secrets to applications: Akv2k8s contains two main components: The akv2k8s Controller syncs Azure Key Vault objects to Kubernetes as native secrets. The akv2k8s Injector injects Azure Key Vault objects as environment variables directly into an application.
  • Security: The akv2k8s Injector is as secure as SSCD since it also injects secrets directly to a Pod. The akv2k8s Controller, on the other hand, is not as secure as SSCD and operates similarly to ESO.
  • AKV2k8s operates as a Deployment: There is one deployment for the controller and one for the injector with a replica count of 1 by default for each. Also, each of those could be disabled or both could be used at the same time. AKV2k8s is also resource efficient compared to SSCD which operates as a daemonset.
  • Contribution and releases: The SSCD project currently has only 25 contributors. The release intervals seem to not be frequent.

Read more:

Azure Secret
Kubernetes Secret
Kubernetes
External Secrets Operator
Azure Key Vault
Recommended from ReadMedium
avatardurairaja sivam
HashiCorp Vault on Kubernetes: Secret Injection Using the External Secrets Operator

In the modern cloud-native ecosystem, securely managing secrets is critical to application deployment and management. HashiCorp Vault is a…

3 min read
avatarJan Kammerath
Inside The Outages: A Dangerous Null Pointer Exception Deployed On Friday

The world went into shock when cyber security firm “Crowdstrike”, a provider of endpoint protection software, released an update on Friday…

6 min read
avatarDhivehi Dev
Securing Kubernetes Applications Exposed via Nginx Ingress with OAuth2 Proxy and OKTA

Securing your applications is crucial, particularly when they are exposed to the public, as unauthorized access can lead to data leaks…

3 min read
avatarLakshmi Thungala
Advanced Kubernetes RBAC: Using ClusterRoles and ClusterRoleBindings for Cluster-Wide Control

3 min read
avatarDhruvin Soni
How to use the Secrets Store CSI driver to mount secrets to Kubernetes pods from Hashicorp Vault?

How to use the Secrets Store CSI driver to mount secrets to Kubernetes pods from Hashicorp Vault?

7 min read
avatarDenis Gorokhov
Kubernetes Authentication Configuration in Vault

Dive into the essential steps for integrating Kubernetes authentication with Vault

3 min read