REDHAT-BUG-2507526: High severity Submariner Submariner CR (IPsec pre-shared key) vulnerability
The Submariner CR exposes a string field for the IPsec pre-shared key. Custom Resources are stored unencrypted in etcd by default (only v1/Secret is encrypted by the OCP KMS provider), are returned by kubectl get submariner -o yaml to anyone with get on the namespaced CR, and are commonly captured in GitOps repos / must-gather bundles. The PSK is identical across all clusters in the mesh, so disclosure on one spoke enables passive decryption of traffic between any two spokes.
Source: Project Glasswing AI-SAST audit of submariner-io/submariner-operator. Finding ID: FIND-003 Assurance: executionproven
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Avoid using an identical IPsec pre-shared key across all clusters in the mesh. Create a distinct IPsec pre-shared key per cluster/mesh instance so that disclosure on one spoke does not enable passive decryption of traffic between other spokes.
Submariner (Submariner Custom Resource) IPsec pre-shared key string field = Use a unique per-cluster/per-mesh PSK and do not reuse the same PSK across clusters
Event History
Frequently Asked Questions
Does the default OpenShift KMS encryption protect this value?
No. Custom Resources are stored unencrypted in etcd by default; the OCP KMS provider encrypts only v1/Secret objects.
Which users or systems can obtain the key?
Anyone with get permission on the namespaced Submariner CR can retrieve it with kubectl get submariner -o yaml. The value may also be exposed through GitOps repositories and must-gather bundles that capture the CR.
How far can disclosure of one cluster's key extend?
The IPsec pre-shared key is identical across all clusters in the mesh. Disclosure from one spoke can enable passive decryption of traffic between any two spokes.
How can an operator identify likely exposure paths?
Review who has get access to the namespaced Submariner CR and check whether its YAML has been captured in GitOps repositories or must-gather bundles. These are identified paths through which the key can be disclosed.