[Security Issue] 📢 Metricbeat Multi-Manifest Security Risk Report

[im-soohyun]

📢 Metricbeat Multi-Manifest Security Risk Report

---

📂 Relevant File

• dev-tools/kubernetes/metricbeat/manifest.debug.multi.yaml

---

📌 Issue Summary

This manifest defines:
✅ Metricbeat DaemonSet (metricbeat-runner)
✅ Metricbeat debug Deployment (metricbeat-debugger)
✅ Linked ServiceAccount and RBAC (ClusterRole, Role, RoleBinding, ClusterRoleBinding)

Key risk factors identified:

• hostNetwork: true → direct host network access
• runAsUser: 0 → container runs with root privileges
• hostPath mounts like /proc, /sys/fs/cgroup
• ServiceAccount with cluster-wide read permissions (ClusterRole)

➡ Combined, these elements create a high-risk attack surface where a single compromised container can escalate to node or even cluster-wide impact.

---

🔍 Detailed Analysis

1️⃣ DaemonSet and Debug Deployment

• hostNetwork: true

  • Shares the container’s network namespace with the host → can bind to host ports, sniff network traffic.

• runAsUser: 0

  • Runs the container as root → increases risk of container escape and kernel exploitation.

• HostPath mounts

  • /proc, /sys/fs/cgroup, /var/lib/metricbeat-data → expose sensitive host system and kernel data to the container.

2️⃣ RBAC (ClusterRole + Role + Binding)

• ClusterRole: metricbeat

  • Grants get, list, watch on:
    • nodes, pods, namespaces, deployments, daemonsets, statefulsets, cronjobs, persistentvolumes, etc.
    • Non-resource endpoints like /metrics.

• Role (metricbeat in kube-system)

  • Grants access to leases (for leader election).

• Role (metricbeat-kubeadm-config)

  • Grants access to the kubeadm-config ConfigMap, which may contain sensitive bootstrap details.

✅ RBAC-Linked Risk
If the ServiceAccount token is stolen inside the container:

• The attacker can enumerate and query sensitive cluster-wide resources.
• Combined with the node-level privileges (hostNetwork, root), this magnifies the blast radius beyond a single pod or node.

---

⚠️ Security Risk Summary

Risk Item	Description
hostNetwork	Enables host-level network access → risk of sniffing, port hijacking, lateral movement.
runAsUser: 0 (root)	Runs as root → increases risk of container escape, kernel-level attacks.
HostPath mounts (/proc, /sys)	Exposes detailed host kernel and process information.
ServiceAccount + ClusterRole	Broad cluster-wide read permissions; if compromised, allows cluster reconnaissance.

---

🛠️ Recommended Actions

✅ Minimize Container Privileges

• Replace runAsUser: 0 with runAsNonRoot: true and assign a non-root UID.
• Apply readOnlyRootFilesystem: true.

✅ Restrict Host Access

• Remove hostNetwork: true unless strictly necessary.
• Limit hostPath mounts to only essential paths.

✅ Tighten RBAC Permissions

• Review the metricbeat ClusterRole:
  • Remove access to unnecessary resources like jobs, cronjobs, persistentvolumes.
• Use namespace-scoped Roles where possible; avoid cluster-wide bindings unless needed.
• Refer to Kubernetes RBAC Best Practices.

✅ Harden Pod Security

• Apply seccomp, AppArmor, or SELinux profiles.
• Follow Kubernetes Pod Security Standards (baseline or restricted level).

✅ Strengthen Image Security

• Avoid latest tags; use pinned and signed images.
• Regularly scan images for known vulnerabilities.

---

📂 References

• Metricbeat Kubernetes Setup Guide
• Kubernetes Pod Security Standards
• RBAC Best Practices
• HostPath Volume Risks

---

❗ Summary

This Metricbeat multi-manifest provides powerful observability but combines container-level privileges (host access, root execution) with RBAC that grants broad cluster-wide read permissions, creating serious security risks.
To reduce the attack surface, it is critical to review RBAC permissions and apply the principle of least privilege.

:kubernetes

[botelastic]

This issue doesn't have a Team:<team> label.

[im-soohyun]

This issue doesn't have a Team:<team> label.

Is it correct to tag like this: Team: kubernetes?