Teneble Scan Findings

[hiteshmathur19]

Trident : 26.02.1:

Recent tenable scan on Trident CSI integrated in CCD showed below vulnerabilities and the the suggestion to address them. Could you please
help in checking whether the suggested solutions are feasible :

1. Unrestricted RBAC create verbs enable privilege escalation in NetApp Trident operator
   Root Cause
   The Trident operator ClusterRole grants unrestricted 'create' on clusterroles and clusterrolebindings (line 386-393) with no resourceNames restriction. The update/patch/delete verbs on the same resources ARE correctly restricted to trident-* names (lines 395-413). This asymmetry indicates the unrestricted 'create' was unintentional — the intent was least-privilege but the create verb was missed.
   Attack Vector
   An attacker who compromises the Trident operator pod or obtains its SA token can create a new ClusterRole with wildcard permissions and bind it to any ServiceAccount. This escalates from 'storage operator admin' to full cluster-admin. The attack requires only standard Kubernetes API calls with the mounted SA token.
   Impact
   Full privilege escalation to cluster-admin. The attacker can create arbitrary ClusterRoles and ClusterRoleBindings, granting any permission to any identity. Combined with F-1002 (unrestricted pods/exec in same ClusterRole), a compromised Trident operator has multiple escalation paths.
   Suggested Approaches
    Add resourceNames restriction to the 'create' verb rule for RBAC resources, matching the pattern already used for update/patch/delete (restrict to trident-* names)
    Verify Trident operator functionality after restriction — confirm it only creates trident-named ClusterRoles during install/upgrade

2. NetApp Trident ClusterRole grants unrestricted cluster-wide secrets CRUD

Root Cause
The trident-operator ClusterRole at csi.yaml:71 lists secrets under the core API group with all seven verbs (get, list, watch, create, delete, update, patch) and no resourceNames field. Because the binding resource is ClusterRole, this permission applies to every Secret in every namespace. The ClusterRoleBinding at csi.yaml:479 activates this for the trident-operator ServiceAccount.
Attack Vector
An attacker who compromises the trident-operator pod (e.g., via a vulnerability in the operator binary or supply-chain compromise) uses the pod's mounted ServiceAccount token to call GET /api/v1/secrets and receive all secret objects across every namespace. Write access allows injecting or overwriting secrets in any namespace.
Impact
Read access to all Secrets in all namespaces including kube-system credentials (etcd encryption keys, cluster CA private keys, service-account signing keys, bootstrap tokens). Write access allows credential injection into other workloads.

Suggested Approaches
 Fix — Scope secrets access: Split the broad ClusterRole secrets rule into a namespace-scoped Role in the operator's own namespace covering only the specific secret names Trident creates and reads. Remove create, delete, update, patch from any cluster-scoped secrets rule — the operator should not need to write secrets outside its own namespace.

3. Unrestricted pods/exec Create
   The same trident-operator ClusterRole (csi.yaml:348) also grants create on pods/exec without a resourceNames restriction. A separate rule at line 358 restricts delete/update/patch to named resources (trident-csi, trident), but create is not covered by that restriction.
   This means a compromised Trident operator pod can exec into ANY pod in ANY namespace — not just Trident pods. This is an incremental capability beyond the secrets CRUD issue: even with cluster-wide secrets read, you cannot exec into arbitrary pods without this permission.
   Fix: Add resourceNames: [trident-csi, trident] to the create verb rule for pods/exec at csi.yaml:348, consistent with the restriction already applied to delete/update/patch at line 358.
   CVSS 3.1: 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) — same vector as F-252. Verdict: CONFIRMED, DOWNGRADED TO BUG (precondition PR:H is the Trident pod compromise).