[Security Issue] 📢 Pixie Operator RBAC & Deployment Security Risk Report

[im-soohyun]

📢 Pixie Operator RBAC & Deployment Security Risk Report

---

📂 Relevant Files and Links

• k8s/operator/deployment/base/rbac.yaml
• k8s/operator/deployment/base/deployment.yaml
• k8s/operator/deployment/base/service_account.yaml

---

📌 Summary of the Issue

Pixie is an open-source cluster monitoring tool.
However, its current deployment configuration contains critical over-permission issues:

✅ The pixie-operator-service-account is
✅ bound to the pixie-operator-role ClusterRole, which
✅ grants verbs: ["*"] (all actions: read, write, delete, modify) across nearly all cluster resources, and
✅ is used by the vizier-operator Deployment.

➡ For a monitoring tool, having full admin-level write and delete rights across the cluster is highly excessive and dangerous.

---

🔍 Detailed Analysis

1️⃣ RBAC (rbac.yaml)

kind: ClusterRole
metadata:
  name: pixie-operator-role
rules:
  verbs: ["*"]  # allows all actions

• The * verbs include:
  • Read-only actions (get, list, watch)
  • And sensitive write actions (create, update, patch, delete)
• Resources affected:
  • Cluster-wide (nodes, clusterroles, clusterrolebindings, customresourcedefinitions)
  • Namespace-scoped (pods, deployments, services, secrets, configmaps)

✅ For monitoring, read-only verbs (get, list, watch) are sufficient.
❗ However, the current setup allows write and admin-level actions, which introduces severe risk.

---

2️⃣ Deployment (deployment.yaml)

spec:
  serviceAccountName: pixie-operator-service-account

• The vizier-operator Pod uses the pixie-operator-service-account.
• Any Kubernetes API requests made by this Pod will fully inherit the ClusterRole’s powerful permissions.

---

3️⃣ ServiceAccount (service_account.yaml)

kind: ServiceAccount
metadata:
  name: pixie-operator-service-account

• By default, the API token is automatically mounted into the Pod.
• If the Pod is compromised, the attacker can use the token to manipulate the entire cluster.

---

⚠️ Security Risks Summary

Risk Item	Description
ClusterRole with */* permissions	Grants full access (read/write/delete) over nearly all Kubernetes resources.
ServiceAccount link	The vizier-operator Pod inherits these permissions through the linked service account.
Violation of Least Privilege (PoLP)	Without a specific need, write/modify/delete actions should be strictly removed; only necessary minimal access should be granted.
Ignoring Open-Source Tool Context	As a monitoring open-source tool, read-only access should be enough; broad write privileges are excessive.

---

🛠️ Recommended Actions

✅ Apply Least Privilege Principle

• Remove verbs: ["*"].
• Limit to only necessary actions, e.g., get, list, watch.
• Assign write privileges (create, update, delete, patch) only when strictly required for specific resources.

✅ Harden ServiceAccount Usage

• Add Pod securityContext settings:

  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  

• Set automountServiceAccountToken: false if the Pod doesn’t need to call the Kubernetes API.

✅ Improve Image Management

• Avoid latest tags.
• Use pinned versions and enforce image signing & vulnerability scanning.

✅ Audit and Monitor RBAC

• Regularly review:

  kubectl get clusterrolebinding pixie-operator-cluster-binding -o yaml
  

• Monitor Kubernetes audit logs for unexpected privilege use.

---

📂 References

• Kubernetes RBAC Best Practices
• Kubernetes Least Privilege Design
• Kubernetes Pod Security Standards

---

❗ Summary:
Even if it’s an open-source monitoring tool, granting it admin-level write access across the entire cluster is highly dangerous.
Unless there’s a specific operational need, write/modify/delete rights should be strictly removed, and the system should adhere to the principle of least privilege.