docs: add SPIRE attestation details and end-to-end example

Author: tossmilestone

docs/en/security/workload_security/spire.mdx

@@ -16,7 +16,6 @@ The SPIRE plugin includes several components to manage identities:
 - **SPIRE Server**: The central authority that manages trust and issues identities.
 - **SPIRE Agent**: Runs on every node and delivers identities to local workloads.
 - **SPIFFE CSI Driver**: A Container Storage Interface driver that mounts SVIDs as volumes into Pods.
-- **SPIRE Controller Manager**: Automates the registration of Kubernetes workloads.
 - **OIDC Discovery Provider**: Exposes an OIDC discovery document for SPIRE's trust domain.
 
 ## Workflow
@@ -84,11 +83,18 @@ Once SPIRE is installed, workloads can obtain their SVIDs using the SPIFFE CSI D
 
 2. **Workload Authentication**: Your application can now use the SPIFFE Workload API at `/run/spiffe.io/public` to retrieve its identity and certificates.
 
+### Attestation
+
+Attestation is the process by which SPIRE identifies and verifies the identity of nodes and workloads.
+
+- **Node Attestation**: The process where a SPIRE Agent identifies itself to the SPIRE Server. In the Alauda Container Platform, this typically uses the `k8s_psat` (Projected Service Account Token) method. The Agent provides a signed Kubernetes service account token, which the SPIRE Server verifies against the Kubernetes API to confirm the Agent's identity and node location.
+- **Workload Attestation**: The process where a workload identifies itself to the local SPIRE Agent. When a workload requests an identity, the Agent inspects the workload's metadata (such as its Kubernetes namespace, service account name, or Unix user ID) using "selectors". These selectors are then compared against registration entries in the SPIRE Server to determine which SVID the workload is authorized to receive.
+
 ### Workload Registration
 
 By default, the **SPIRE Controller Manager** automatically creates SPIRE entries for Kubernetes workloads based on their labels or service accounts. You can customize this behavior using annotations on your workloads.
 
-### End-to-End Implementation Example
+## End-to-End Implementation Example
 
 The following example demonstrates a complete SPIRE deployment showing how to set up mutual TLS (mTLS) authentication between workloads using SPIFFE identities.
 
@@ -113,62 +119,9 @@ The architecture consists of:
 
 Before starting, ensure you have:
 
-- A running Kubernetes cluster with storage component deployed
-- Kubelet API listening on 127.0.0.1
 - The `example` namespace created: `kubectl create namespace example`
 
-### SPIRE Deployment
-
-Deploy SPIRE using the official Helm chart with production-ready configuration:
-
-1. Create a `values.yaml` file with the following content:
-
-   ```yaml
-   global:
-     openshift: false
-     spire:
-       recommendations:
-         enabled: true
-       namespaces:
-         create: true
-       ingressControllerType: ''
-       clusterName: example-cluster
-       trustDomain: example.org
-       caSubject:
-         country: CN
-         organization: Example
-         commonName: example.org
-       persistence:
-         storageClass: your-storage-class
-   ```
-
-2. Deploy SPIRE CRDs and main components:
-
-   ```bash
-   helm upgrade --install --create-namespace -n spire spire-crds spire-crds \
-     --repo https://spiffe.github.io/helm-charts-hardened/
-
-   helm upgrade --install -n spire spire spire \
-     --repo https://spiffe.github.io/helm-charts-hardened -f values.yaml
-   ```
-
-3. Verify all pods are running:
-
-   ```bash
-   kubectl get pods -n spire
-   ```
-
-   Expected output should show all SPIRE components in `Running` state:
-
-   ```
-   NAME                                                  READY   STATUS    RESTARTS   AGE
-   spire-agent-xxx                                       1/1     Running   0          17h
-   spire-server-0                                        2/2     Running   0          18h
-   spire-spiffe-csi-driver-xxx                           2/2     Running   0          19h
-   spire-spiffe-oidc-discovery-provider-xxx              2/2     Running   0          17h
-   ```
-
-### Example Workload Registration
+### Workload Registration
 
 Register the client and server workloads with SPIRE:
 
@@ -245,7 +198,7 @@ spec:
             - 127.0.0.1:8080
             - --allow-uri
             - spiffe://example.org/ns/example/sa/client-sa
-          image: docker-mirrors.alauda.cn/ghostunnel/ghostunnel:v1.9.0
+          image: ghostunnel/ghostunnel:v1.9.0
           imagePullPolicy: Always
           name: ghostunnel
           ports: