You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Medium] ate-controller ServiceAccount can get/list/watch every Secret in the cluster #2929
The egress MITM trust controller declares its Secret RBAC without a namespace, so controller-gen puts secrets: get, list, watch into the cluster-scoped ClusterRole ate-controller, and a ClusterRoleBinding grants it to the ate-controller ServiceAccount. The controller only reads one Secret (ate-system/egress-mitm-ca-pool).
The controller's own cache is already scoped to the single Secret (cmd/atecontroller/main.go#L131-L147, FieldSelector: metadata.name=egress-mitm-ca-pool in the system namespace), so the cluster-wide grant isn't needed at runtime.
Impact
Anyone who gets the ate-controller token (a compromise of the controller pod, a node-level attacker on its node, or a leaked token) can read every Secret in every namespace, including other tenants' and system credentials. The runtime cache scoping doesn't limit what the token itself is allowed to do.
Suggested fix
Change the marker to //+kubebuilder:rbac:groups=core,namespace=ate-system,resources=secrets,verbs=get;list;watch so controller-gen emits a namespaced Role, bind it with a RoleBinding in ate-system, and regenerate manifests/ate-install/generated/role.yaml.
If possible, also restrict the rule with resourceNames: [egress-mitm-ca-pool]. get honors it; list/watch with a field selector on metadata.name also work under resourceNames.
Add a manifest test asserting that the ate-controller ClusterRole contains no secrets rule.
Related
#2165 (namespace scoping of controller informers), #2901 (trimming ate-api-server RBAC).
Activity