[Security Issue] 📢 Crane metric-adapter RBAC Vulnerability Report

[im-soohyun]

📢 Crane metric-adapter RBAC Vulnerability Report

🔗 Related file: gocrane/crane rbac.yaml

---

📌 Summary

This Kubernetes RBAC configuration contains overly permissive permissions (Overscoped Permissions).
Specifically, the ClusterRole granting apiGroups: ['*'], resources: ['*'], and verbs: ['*'] effectively provides full cluster-admin privileges, which poses a serious security risk.

---

🔍 Detailed Analysis

1️⃣ Vulnerable Resource: ClusterRole metric-adapter

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: metric-adapter
rules:
  - apiGroups: [ '*' ]
    resources: [ '*' ]
    verbs: [ '*' ]

• Issue:
  • Grants access to all API groups (*), all resources (*), and all actions (*).
  • This is effectively the same as cluster-admin privileges,
    allowing the metric-adapter service account to access/modify/delete any resource in the cluster.
  • However, the original purpose of metric-adapter is only to collect and provide metrics,
    so cluster-wide admin-level permissions are unnecessary.

---

2️⃣ Binding Analysis: Who is receiving this permission?

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: metric-adapter
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: metric-adapter
subjects:
  - kind: ServiceAccount
    name: metric-adapter
    namespace: crane-system

• metric-adapter ServiceAccount (in the crane-system namespace) is bound to this ClusterRole.
• If the metric-adapter Pod or related container is compromised,
  an attacker could escalate privileges and gain full control over the cluster.

---

3️⃣ Additional Permission Issue: custom-metrics-reader

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-reader
rules:
  - apiGroups:
      - "external.metrics.k8s.io"
    resources:
      - '*'
    verbs:
      - '*'

• Issue:
  • Allows all actions (*) on external metric resources.
  • Typically, only read permissions are required, so using * verbs is excessive.
  • Should be limited to verbs: ['get', 'list', 'watch'].

---

⚠️ Vulnerability Summary

Issue Item	Description
Overly broad ClusterRole	Grants */*/* permissions across all resources, API groups, and actions
Unnecessary wide verbs	custom-metrics-reader allows * verbs (should only need read permissions)
Cluster-wide binding	metric-adapter ServiceAccount receives cluster-wide admin-level permissions
Potential attack vector	If metric-adapter Pod is compromised, attacker can take over all resources (including kube-system), leading to RCE and lateral movement

---

🛠️ Recommendations

✅ Apply the Principle of Least Privilege (PoLP):

• For the metric-adapter ClusterRole:
  • Explicitly specify only the required resources and verbs (e.g., get, list, watch).
  • Avoid using */*/* under any circumstances.

✅ Custom Metrics Reader:

• Limit verbs to ['get', 'list', 'watch'].

✅ Minimize Cluster-wide Bindings:

• Avoid ClusterRoleBinding unless absolutely necessary.
• Prefer Role + RoleBinding scoped to the specific namespace.

✅ Enhance Security Monitoring:

• Add security monitoring for the metric-adapter Pod.
• If needed, apply PodSecurityPolicy or NetworkPolicy to restrict outbound access.

---

📂 References

• Kubernetes RBAC Best Practices
• Kubernetes Least Privilege Design