[Security Issue] metric-adapter ClusterRole grants full cluster-wide privileges

[im-soohyun]

🔐 [Security Issue] metric-adapter ClusterRole grants full cluster-wide privileges

The current configuration of the metric-adapter component defines an overly permissive ClusterRole and applies it directly to a running pod through a ServiceAccount and ClusterRoleBinding. This creates a critical security risk where compromising a single pod could lead to complete cluster takeover.

---

🔍 Misconfigured RBAC Flow with Source Links

---

1️⃣ Overprivileged ClusterRole definition

📄 rbac.yaml lines 1–8

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: metric-adapter  # <-- (A) overly permissive role
rules:
  - apiGroups: [ "*" ]
    resources: [ "*" ]
    verbs: [ "*" ]

This ClusterRole grants full access to all API groups, resources, and actions, including reading secrets, modifying configurations, deleting deployments, and more.

---

2️⃣ Binding the ClusterRole to a ServiceAccount

📄 rbac.yaml lines 100–111

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: metric-adapter
roleRef:
  kind: ClusterRole
  name: metric-adapter  # <-- (A) reference to the powerful role
subjects:
  - kind: ServiceAccount
    name: metric-adapter  # <-- (B) service account that receives the permissions
    namespace: crane-system

This binding gives full cluster access to the metric-adapter ServiceAccount.

---

3️⃣ ServiceAccount Definition

📄 deployment.yaml lines 1–5

apiVersion: v1
kind: ServiceAccount
metadata:
  name: metric-adapter  # <-- (B) defined ServiceAccount
  namespace: crane-system

The above ServiceAccount is the subject of the previous ClusterRoleBinding.

---

4️⃣ ServiceAccount Used in Deployment

📄 deployment.yaml line 27

spec:
  template:
    spec:
      serviceAccountName: metric-adapter  # <-- (B) the privileged ServiceAccount in use
      containers:
        - name: metric-adapter
          image: docker.io/gocrane/metric-adapter:v0.10.0

The metric-adapter pod is now running with cluster-admin equivalent privileges.

---

⚠️ Realistic Threat Scenarios

Scenario	Description
Pod Compromise → Cluster Takeover	If the metric-adapter pod is compromised via a vulnerability, the attacker gains full control of the cluster.
Secrets Exfiltration	Attacker can access all secrets in all namespaces, including kube-system.
RBAC Abuse	The attacker can grant themselves or other pods more privileges, create backdoors, or modify policies.
Workload Tampering	Delete or modify other workloads, inject malicious deployments, or affect critical services.
Lateral Movement	Pivot into internal services such as Prometheus, databases, or private applications.

---

✅ Recommendations

1. Replace the wildcard-based ClusterRole with a least privilege policy:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: metric-adapter
rules:
  - apiGroups: ["custom.metrics.k8s.io"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]

2. If possible, switch from a ClusterRole to a namespace-scoped Role and use RoleBinding instead.

3. Audit and remove duplicate or unnecessary RBAC definitions. Add CI security checks (e.g., using Polaris, OPA Gatekeeper, or kubeaudit).

---

🚨 Suggested Action

This is a critical security vulnerability where a single container exploit could lead to full cluster compromise.
It is strongly recommended that the team opens a pull request (PR) immediately to address this misconfiguration.

[github-actions]

You may look for issues:

1. 54% [Security Issue] 📢 Crane metric-adapter RBAC Vulnerability Report #920

_{🤖 By issues-similarity-analysis}