The External Secrets Enterprise is product suite is a premium product. It requires a specific subscription. Contact us for more information.

​
Overview

The External Secrets Enterprise (ESE) Federation feature allows you to establish a centralized External Secrets instance (the Federation Server) that can securely serve secret data to authenticated and authorized clients in other Kubernetes clusters. These clients can be esi-cli instances or other ESE instances acting as Federation Clients. This enables scenarios where secrets are managed by a central ESE deployment, but consumed by applications across different clusters, without those applications or client ESE instances needing direct access to the ultimate secret backends (like Vault, GCP SM, etc.) managed by the Federation Server.

​
Key Terminology

Understanding these terms is crucial for working with ESI Federation:
  • Federation Server:
    • An External Secrets Enterprise instance specifically configured with federation capabilities.
    • It exposes secure API endpoints to serve secret data to authenticated clients.
    • It is responsible for fetching secrets from backend stores (e.g., Vault, AWS Secrets Manager, GCP Secret Manager) based on its own SecretStore and ClusterSecretStore configurations.
  • Federation Client:
    • An entity that consumes secrets from a Federation Server.
    • Common clients include:
      • esi-cli: The command-line interface can directly query a Federation Server.
      • Other ESE instances: An ESE deployment in a different cluster can be configured to act as a client to a central Federation Server.
  • Authentication:
    • Federation Clients authenticate to the Federation Server using Kubernetes Service Account (SA) JSON Web Tokens (JWTs) from their own cluster.
    • The Federation Server validates these tokens by fetching the client cluster’s public keys (JWKS).
  • Authorization:
    • Access control is managed on the Federation Server.
    • This is achieved using Authorization Custom Resources, which define policies specifying:
      • Which client identities (Service Accounts from specific federated client clusters) are recognized.
      • Which resources (e.g., ClusterSecretStores or Generators) on the Federation Server these clients are permitted to access.
These core concepts form the foundation of how ESI Federation provides secure, centralized secret management for distributed applications.