Akeyless Injector Vs External Secrets Operator
The following is a comparison between the External Secrets Operator and the Akeyless Injector. Both solutions manage secrets in Kubernetes, but they differ in approach, storage, and security model.
Akeyless K8s Secrets Injector
A solution that injects secrets into pods at runtime without storing them in Kubernetes secrets. Containers within the pod can consume those secrets without interacting with Akeyless. The injector is a Kubernetes
MutatingAdmissionWebhook controller that modifies annotated pods, delivering secrets as environment variables or files via an init container. Updates can be handled automatically using rollout restart.
External Secrets Operator (ESO)
An open-source Kubernetes operator that integrates external secret managers like Akeyless. It fetches secrets via external APIs, converts them into Kubernetes Secrets, and stores them securely in the cluster storage. Automatic secret refresh is supported without changing the application, also pushing secrets back to Akeyless is supported.
Akeyless Injector vs. External Secrets Operator
The following table compares key aspects of the Akeyless Kubernetes Injector and the External Secrets Operator (ESO), focusing on how each solution handles secret management within Kubernetes environments.
| Feature | Akeyless Injector | External Secrets Operator |
|---|---|---|
| Secret Types | Static Rotated Dynamic Certificates USC | Static Rotated Dynamic Certificates |
| Authentication Methods | K8s API Key Azure AD AWS_IAM GCP | K8s API Key Azure AD AWS_IAM GCP |
| How secrets are fetched | Secrets are injected into pods at runtime, and each pod requests the relevant secret it needs | Secrets are synced from external systems into K8s Secret resources using a dedicated external secret resource per secret. All requests are done via the controller |
| Access Control | Access control is done via Akeyless RBAC, where different claims can be used to control the RBAC itself. | Access control is done on Akeyless and on K8s itself, as it creates K8s secrets. In addition, due to the architecture of a single requestor, only the SA reference can be used in addition to limit access via Akeyless RBAC. |
| Secret lifetime | The secret exists only while the pod is running | Secret stays in the cluster until it’s manually deleted |
| K8s Integration type | Seamless as K8s admission controller | Uses a controller that interacts with K8s secret |
| Secret storage location | The secrets are injected directly into the pod. Can be saved in a specific location with custom file permissions | Secrets are stored as Kubernetes Secrets |
| Secret Automatic Refresh | Support of rollout restart upon any change of a secret, without periodic checks | Periodic checks for secret changes (many requests) without auto detection. |
| Cache | Bypass cache is supported to fetch the latest secret value. This can be controlled globally for all deployments, to fetch the secret latest value, Can be controlled globally for all deployments, or explicitly. | Not supported, in case the Gateway cache is used, first it will provide a cached version when it exists |
| Observability and Monitoring | All secret accesses are logged in the Akeyless audit logs, recording who accessed what, when, and from where, as well as telemetry metrics available | All secrets access are logged in the Akelyess audit logs. ESO sends out K8s events when it syncs secrets, runs into errors while fetching them, or updates the status of an ExternalSecret. |
| Deployment | Deployed via a Helm chart. Supporting global settings in addition to the settings each deployment can be set with via annotations. | Deployed via a Helm chart. Uses K8s resources like ExternalSecret, SecretStore, etc, to manage and settings. |
Conclusion
Kubernetes is not a secrets management solution. It does support native secrets storage, but those are not encrypted. It does come with a built-in RBAC model, but this is not easy to manage at scale and does not provide the same level of fine-grained policy control as Akeyless. Once a Kubernetes secrets are defined, they are stored in the Kubernetes storage server and presented to pods only during pod creation. meaning it is a common issue where secrets are being stale, outdated, or expired, requiring additional workflows to update and rotate the secrets, and then re-deploy the application to use the new version of the secrets.
Updated 1 day ago