Security and RBAC · New in v0.3.0

Security posture and RBAC, in the free application

PodSteer's Security section holds three pages: Posture, the privileges your pod specs take — privileged mode, host namespaces, dangerous capabilities, running as root; Vulnerabilities, what a scanner already in your cluster has found; and Permissions, which asks your API server what an account can do and quotes the answer.

Download PodSteer All features

Posture, from the specs you wrote

Privileged containers, shared host namespaces, allowPrivilegeEscalation, dangerous added capabilities and UID 0 are reported where a spec asks for them. They are informational: every real cluster runs privileged network and storage agents, and a warning for each would turn every cluster permanently yellow.

The Posture page listing 23 findings in one table: pods sharing the node's network or PID namespace, privileged containers in four kube-proxy pods and platform/net-debug, and kindnet containers adding NET_ADMIN and NET_RAW, each row naming the workload, its namespace and what it takes. The Posture page listing 23 findings in one table: pods sharing the node's network or PID namespace, privileged containers in four kube-proxy pods and platform/net-debug, and kindnet containers adding NET_ADMIN and NET_RAW, each row naming the workload, its namespace and what it takes.
The privileges workloads take. Read from the pod specs, and reported as notes, because every real cluster runs a few privileged agents.

Vulnerabilities, from the scanner you run

If the Trivy Operator is installed, PodSteer reads the reports it wrote: severities on the pod list, fixable findings counted, and how many other workloads run the same image — so one image bump reads as one fix, not twelve problems.

When there is no scanner, no permission, nothing scanned yet or a failed read, the page says which. "Nothing found" and "nothing looked" are different, and only one is good news.

Permissions, answered by the API server

  • What can I do in this namespace — one SelfSubjectRulesReview, answered by the API server, in the same table every list uses.
  • Can I… — an access review from the toolbar, with the server's allowed, denied and reason quoted verbatim.
  • Who holds a role — every binding that grants it, across the whole cluster, from the toolbar.
  • A role's risky rules flagged: wildcards, escalate, bind, impersonate, cluster-wide Secret reads, creating pods, and bindings to cluster-admin.
The Permissions page's Who holds a role dialog inspecting the ClusterRole ops-automation: flagged for granting every verb, every resource and a read of every Secret, each flag saying what it permits and how to narrow it, above the start of the role's rules. The Permissions page's Who holds a role dialog inspecting the ClusterRole ops-automation: flagged for granting every verb, every resource and a read of every Secret, each flag saying what it permits and how to narrow it, above the start of the role's rules.
A role, inspected. What a role reaches, flagged with what each rule permits, from a dialog on the Permissions page.

Be honest

What it does not do.

  • PodSteer scans nothing and ships no vulnerability database. It quotes what your scanner wrote.
  • There is no compliance score, and there will not be one.
  • Checking another account's permissions needs a privilege most accounts do not hold; the page says so when it is refused.
  • Volume-based risks such as hostPath mounts are not assessed yet.

Read next

Operator panels

Built-in views for cert-manager, KEDA, External Secrets, Argo Rollouts, Trivy, Karpenter, Gateway API and more — no plugin API, nothing to install.

Helm releases

Every Helm release and revision, listed from labels alone; one revision's values and manifest read only when you ask.

Cluster assessment

Ranked findings instead of a pod list: crash loops, OOM kills, pods that will never schedule, sizing problems — each with what to do about it.

Compared with other tools: PodSteer vs Lens Desktop · PodSteer vs Freelens · PodSteer vs Headlamp