Description:

API key secrets with multiple client IDs are incorrectly filtered during caching, keeping only the lexicographically first client. This breaks authentication for all other clients.

According to the API key auth design, secrets should use client IDs as keys:

apiVersion: v1
kind: Secret
metadata:
  name: apikey-secret
data:
  client1: a2V5MQ==
  client2: a2V5Mg==
  client3: a2V5Mw==

The cache transform function transformSecretData in internal/provider/kubernetes/helpers.go (introduced in #8045) applies expectedAndFirstFallbackFilter, which only keeps:

• Predefined keys (e.g., tls.crt, tls.key, etc.)
• The first key alphabetically as fallback

Since API key client IDs are arbitrary and not in the predefined list, only client1 gets cached. client2 and client3 are dropped, causing authentication failures.

Repro steps:

1. Create a secret with multiple API key clients:

apiVersion: v1
kind: Secret
metadata:
  name: apikey-secret
  namespace: default
data:
  client1: c3VwZXJzZWNyZXQx  # supersecret1
  client2: c3VwZXJzZWNyZXQy  # supersecret2

2. Create a SecurityPolicy referencing the secret:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: api-key-policy
  namespace: default
spec:
  targetRefs:
    - kind: HTTPRoute
      name: backend
  apiKeyAuth:
    credentialRefs:
      - name: apikey-secret
    extractFrom:
      - headers: ["x-api-key"]

3. Test authentication:
   • Request with x-api-key: supersecret1 → ✅ Works (first client cached)
   • Request with x-api-key: supersecret2 → ❌ Fails (second client dropped)

Environment:

Introduced in #8045 (merged Jan 28, 2026). Affects v1.7.0 and main branch.

Logs:

None provided as replication is simple.