[Feature Request] Kubernetes Integration via External Secrets Operator (ESO)

[chiqors]

Description

Currently, Keyshade is a fantastic tool for managing secrets, but it lacks a native way to sync those secrets into Kubernetes. While the CLI is great for local development and CI/CD, production Kubernetes environments increasingly rely on the External Secrets Operator (ESO) to bridge the gap between external secret managers and native K8s Secrets.

Integrating Keyshade with ESO would allow users to treat Keyshade as a "Source of Truth" while maintaining the security best practices of the Kubernetes ecosystem.

I have also opened a corresponding feature request on the External Secrets Operator side: external-secrets/external-secrets#5903.

The Problem

Without an ESO provider, users have to:

1. Manually create K8s secrets (prone to drift).
2. Use custom scripts in CI/CD to inject secrets (security risk).
3. Use the Keyshade CLI in init-containers (adds complexity and overhead).

Proposed Solution

Implement a Keyshade Provider for the External Secrets Operator. This would involve:

• SecretStore / ClusterSecretStore: A resource to define the Keyshade API endpoint and authentication (e.g., via a Service Token).
• ExternalSecret: A resource to map specific Keyshade environment variables/secrets to a K8s Secret.

The References

• External Secrets Operator Documentation
• Example: Infisical ESO Provider