[Security Issue] 📢 Crane craned RBAC Vulnerability Report

[im-soohyun]

📢 Crane craned RBAC Vulnerability Report

🔗 Related file 01 : deploy/craned/rbac.yaml

🔗 Related file 02 : deploy/metric-adapter/rbac.yaml

---

📌 Summary

This Kubernetes RBAC configuration contains overscoped permissions and unnecessary ClusterRoleBinding issues.
Specifically, the ClusterRole grants '*' resources and '*' verbs to certain API groups (analysis.crane.io, autoscaling.crane.io, prediction.crane.io), effectively allowing all actions.
This severely violates the Principle of Least Privilege (PoLP) and can lead to widespread cluster impact if the service account is compromised.

---

🔍 Detailed Analysis

1️⃣ Vulnerable Resource: ClusterRole craned

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: craned
rules:
- apiGroups:
  - analysis.crane.io
  resources:
  - "*"
  verbs:
  - "*"
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - "*"
- apiGroups:
  - autoscaling.crane.io
  resources:
  - "*"
  verbs:
  - "*"
- apiGroups:
  - prediction.crane.io
  resources:
  - "*"
  verbs:
  - "*"

• Issue:
  • Grants */* (all resources, all actions) across all crane-related API groups.
  • Also grants all verbs on HPA (autoscaling) resources.
  • Should be limited to only required verbs like get, list, watch; full * verbs are excessive.
  • Especially for custom API groups (analysis, autoscaling.crane.io, prediction.crane.io), unnecessary write permissions can allow attackers to manipulate the system.

---

2️⃣ Binding Analysis: Who receives these permissions?

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

• craned ServiceAccount (in the crane-system namespace) is bound to cluster-wide permissions.
• If the Pod or container is compromised, the attacker can manipulate HPA, analysis, and prediction resources freely.
• Misusing scaling resources can lead to service outages, overload, or denial-of-service (DoS) attacks.

---

3️⃣ Role Analysis (namespace scope)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: craned
  namespace: crane-system
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - secrets
  verbs:
  - create
- apiGroups:
  - ""
  resourceNames:
  - craned
  resources:
  - configmaps
  verbs:
  - get
  - patch
  - update

• Issue:
  • Holds create and modify permissions for secrets and configmaps within the namespace.
  • Secrets access is particularly sensitive and can lead to exposure of service account tokens, passwords, or other confidential data.
  • Should ideally limit resource names or remove unnecessary create/patch permissions.

---

⚠️ Vulnerability Summary

Issue Item	Description
Overscoped ClusterRole	Grants */* permissions to analysis.crane.io, autoscaling.crane.io, and prediction.crane.io API groups
Cluster-wide Binding	ClusterRoleBinding assigned to craned ServiceAccount, granting cluster-wide impact
Secrets/ConfigMaps	Holds create and modify permissions for secrets and configmaps within the namespace, risking sensitive leaks
Potential Attack Path	If craned Pod is compromised, attacker can manipulate cluster resources (scaling, prediction, analysis), causing DoS or lateral movement

---

🛠️ Recommendations

✅ Apply Principle of Least Privilege (PoLP):

• Replace */* in the ClusterRole with only required resources and verbs (e.g., get, list, watch).
• Especially minimize write permissions for autoscaling, analysis, and prediction APIs.

✅ Minimize ClusterRoleBinding:

• Prefer Role + RoleBinding scoped to the namespace instead of ClusterRoleBinding when possible.

✅ Restrict Secrets Access:

• Limit secrets access to specific named resources, or set it to read-only if applicable.

✅ Enhance Security Monitoring:

• Add security monitoring on the craned Pod.
• Consider applying PodSecurityPolicy or NetworkPolicy to restrict external access.

---

📂 References

• Kubernetes RBAC Best Practices
• Kubernetes Least Privilege Design
• Source YAML on GitHub

[github-actions]

You may look for issues:

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

_{🤖 By issues-similarity-analysis}