feat: update apiversions and add spiffefederation docs

docs/enterprise/externalsecrets/federation/example.mdx

@@ -51,7 +51,7 @@
    This CR registers `client-cluster-alpha` with the Federation Server.
    ```yaml
    # Filename: kf-client-cluster-alpha.yaml on cluster-main
-   apiVersion: federation.external-secrets.io/v1alpha1
+   apiVersion: identity.federation.external-secrets.io/v1alpha1
    kind: KubernetesFederation
    metadata:
      name: client-cluster-alpha
@@ -86,7 +86,7 @@
 ### 2. On the Client Cluster (`client-cluster-alpha`)
 
 **A. Create the Service Account:**
    Ensure the `prometheus-esi-client` ServiceAccount exists in the `monitoring` namespace.
    ```yaml
    # Filename: sa-prometheus-esi-client.yaml on client-cluster-alpha
    apiVersion: v1

docs/enterprise/externalsecrets/federation/server-setup.mdx

@@ -1,6 +1,6 @@
 ---
 title: Federation Server Setup
 description: Learn how to configure the Federation Server, including CRDs and API endpoints.
 ---
 
 <Note>
@@ -9,31 +9,68 @@
 </Note>
 
 
 Setting up an External Secrets Ultimate Edition   instance as a Federation Server involves configuring specific Custom Resources (CRDs) that define how it interacts with client clusters and what permissions clients have. The server also exposes dedicated API endpoints for clients to request secrets.
 
 ## Custom Resource Definitions (CRDs)
 
 The federation feature introduces two key Custom Resource Definitions that are typically applied on the **Federation Server** cluster.
 
-### 1. `KubernetesFederation`
+## 1. Identity
 
-*   **API Group**: `federation.external-secrets.io/v1alpha1`
+The Identity resource defines how client clusters authenticate to the Federation Server. Each federation relationship specifies the authentication mechanism and trust parameters used when validating incoming requests.
+
+Currently, there are two supported identity types:
+
+* `KubernetesFederation`
+* `SpiffeFederation`
+
+Both CRDs belong to the same API Group, but they differ in how trust is established — the first uses a Kubernetes API endpoint (JWKS-based), while the second uses a SPIFFE Trust Domain.
+
+#### 1.1. `KubernetesFederation`
+
+*   **API Group**: `identity.federation.external-secrets.io/v1alpha1`
 *   **Kind**: `KubernetesFederation`
 *   **Scope**: Cluster
 *   **Purpose**: Defines a named federation relationship with a client Kubernetes cluster. It essentially registers a client cluster with the Federation Server, enabling the server to validate tokens issued by that client cluster.
 *   **Spec Fields**:
     *   `url` (string, **required**): The Kubernetes API Server URL of the client cluster (e.g., `https://kubeapi.client-cluster.example.com`). This URL is used by the Federation Server to construct the JWKS (JSON Web Key Set) URI for the client cluster, allowing it to fetch the public keys needed to validate Service Account (SA) tokens issued by that client cluster.
 
+The Federation Server uses the client cluster’s API Server URL to derive its JWKS (JSON Web Key Set) endpoint. The JWKS keys are then used to validate the digital signatures of incoming Kubernetes SA tokens.
+
+
 **Example `KubernetesFederation` CR:**
 ```yaml
-apiVersion: federation.external-secrets.io/v1alpha1
+apiVersion: identity.federation.external-secrets.io/v1alpha1
 kind: KubernetesFederation
 metadata:
   name: my-client-cluster # A descriptive name for the client cluster
 spec:
   url: https://api.my-client-cluster.example.com
 ```
 
+#### 1.2. `SpiffeFederation`
+
+*   **API Group**: `identity.federation.external-secrets.io/v1alpha1`
+*   **Kind**: `SpiffeFederation`
+*   **Scope**: Cluster
+*   **Purpose**: Defines a named federation relationship with a SPIFFE-enabled environment, allowing the Federation Server to trust and validate SPIFFE identities (spiffe://...) issued by that external trust domain.
+*   **Spec Fields**:
+    *   `trustDomain` (string, **required**): The SPIFFE Trust Domain (e.g. `spiffe://client.example.com`). Used to locate the bundle endpoint and validate SVIDs issued by that domain.
+
+Unlike `KubernetesFederation`, which relies on the Kubernetes API’s JWKS endpoint, `SpiffeFederation` establishes trust based on a SPIFFE Trust Domain and its associated bundle endpoint.
+This allows the Federation Server to verify SVIDs (SPIFFE Verifiable Identity Documents) presented by workloads in the federated domain.
+
+
+**Example `SpiffeFederation` CR:**
+```yaml
+apiVersion: identity.federation.external-secrets.io/v1alpha1
+kind: KubernetesFederation
+metadata:
+  name: my-client-cluster # A descriptive name for the client cluster
+spec:
+  trustDomain: spiffe://client.example.com
+```
+
 ### 2. `Authorization`
 
 *   **API Group**: `federation.external-secrets.io/v1alpha1`
@@ -51,9 +88,9 @@
     *   `allowedGenerators` (array of objects, optional): A list of `Generator` resources (defined on the Federation Server) that the client identity is allowed to access. Each object in the list should specify:
         *   `name` (string, **required**): The name of the Generator.
         *   `kind` (string, **required**): The kind of the Generator (e.g., `VaultDynamicSecret`, `Password`).
         *   `namespace` (string, **required**): The namespace where the Generator is defined on the Federation Server.
     *   `allowedGeneratorStates` (array of objects, optional): Advanced permission for allowing the client to manage (e.g., delete) `GeneratorState` objects on the Federation Server. Each object specifies:
         *   `namespace` (string, **required**): The namespace on the Federation Server where the `GeneratorState` objects reside.
 
 **Example `Authorization` CR:**
 ```yaml
@@ -77,7 +114,7 @@
 ```
 
 <Warning>
   Both `KubernetesFederation` and `Authorization` CRs must be correctly configured on the Federation Server for clients to authenticate and be authorized to access secrets.
 </Warning>
 
 ## Federation Server API Endpoints
@@ -97,11 +134,11 @@
     *   **Permissions**: Requires appropriate `allowedGeneratorStates` or specific generator-level permissions.
 
 *   `POST /generators/:generatorNamespace/revoke`
     *   **Purpose**: Allows an authorized client to request revocation of credentials related to a generator type within a namespace (e.g., revoking all tokens issued by a specific Vault PKI generator for that client).
     *   **Permissions**: Depends on the generator's capabilities and specific authorization rules.
 
 <Info>
   The request body for these endpoints, beyond the authentication details (like `ca.crt` for the client cluster's JWKS endpoint), may include parameters specific to the action, such as inputs for a generator. `esi-cli` handles the construction of these requests based on its command-line flags.
 </Info>
 
 Properly configuring these CRDs and understanding the API endpoints are key to operating a secure and functional ESI Federation Server.

docs/enterprise/externalsecrets/tutorials/dynamic-credentials.mdx

@@ -22,7 +22,7 @@
 *   **Pod Admission Webhook**: Intercepts Pod creation/update events and automatically injects and configures an `esi-cli` init container based on Pod annotations.
 *   **`esi-cli`**: Runs as an init container within your application Pod. It communicates with the ESI Federation server to fetch dynamic credentials from a `Generator` and injects them into the main application container (as environment variables or files).
 *   **ESI Federation**: Enables `esi-cli` (as a client) to securely request secrets from a central Federation Server. This server can be the same ESE instance managing the Pod or a separate, dedicated ESE instance.
 *   **`Generators`**: Custom Resources (CRs) deployed on the Federation Server. They define how to create dynamic secrets on-the-fly by interacting with backend systems like HashiCorp Vault, AWS IAM, GCP IAM, etc.
 
 ## The Dynamic Credential Workflow
 
@@ -67,7 +67,7 @@
 Create an `Authorization` CR on the ESE Federation Server to allow the Service Account of your application Pod to use the `vault-app-creds-generator`.
 
 ```yaml
-apiVersion: federation.external-secrets.io/v1alpha1
+apiVersion: identity.federation.external-secrets.io/v1alpha1
 kind: KubernetesFederation
 metadata:
   name: my-app-cluster