An attacker who has gained the ability to create pods or influence pod specifications - for instance, through a compromised developer account or an application-layer injection vulnerability - can mount the gather service account to an attacker-controlled pod. Once the pod is running with this identity, the attacker can use standard Kubernetes API calls to retrieve secrets, such as API keys, database credentials, or TLS certificates, leading to a complete compromise of sensitive information stored within the cluster.

Attack Chain

1. Attacker identifies a vulnerability (e.g., remote code execution or unauthorized access) allowing pod creation or modification within the cluster.
2. Attacker crafts a malicious pod specification that mounts the gather service account using serviceAccountName: "gather".
3. Attacker deploys the malicious pod into the cluster via the API server.
4. The pod executes, gaining the elevated permissions associated with the gather service account.
5. Attacker executes kubectl get secrets --all-namespaces or makes equivalent API requests from within the pod.
6. The Kubernetes API server grants the request due to the over-privileged ClusterRole.
7. Attacker exfiltrates gathered secrets to external infrastructure to achieve final objectives.

Impact

Successful exploitation results in full exposure of cluster-wide secrets, including but not limited to database credentials, service-to-service authentication tokens, and TLS private keys. This can facilitate lateral movement within the cluster, escalation to other services, and access to external resources secured by the compromised credentials.

Recommendation

1. Review the current cluster-wide RBAC policies for the insights-operator and restrict the scope of the insights-operator-gather role to only those namespaces and resources strictly necessary for its telemetry-gathering function.
2. Implement Kubernetes Admission Controllers or Policy-as-Code (such as OPA Gatekeeper or Kyverno) to prevent the arbitrary mounting of sensitive service accounts by user-defined pods.
3. Audit existing pods and service account bindings to identify unauthorized use of the gather service account.
4. Monitor cluster API audit logs for suspicious get or list requests on secrets resources originating from the gather service account.