Use Case: Container & K8s

Kubernetes RBAC abuse

A service account in the data-processing namespace just received cluster-admin via a manually created ClusterRoleBinding. No Terraform run. No ticket. ManySignal flagged it in 45 seconds.

Book a demo Container attack surface

Attack scenario

Cluster-admin in the data namespace

Kubernetes RBAC is the primary authorization control for the entire cluster. An attacker who compromises a low-privilege pod can attempt to escalate to cluster-admin by exploiting a misconfigured ClusterRole that includes the ability to bind new roles, or by directly creating a ClusterRoleBinding if the initial compromise included a high-privilege service account token mounted in the pod's filesystem.

This is the cloud-native equivalent of Active Directory privilege escalation. Once the attacker has cluster-admin, they can read all secrets across all namespaces, exec into any pod, and deploy new workloads. The Kubernetes API server audit log records every RBAC change — but without a detection layer watching those logs in real time, the changes go unnoticed.

Detection logic

rule: k8s_rbac_privilege_escalation
type: audit_event + posture_check
sources:
  - kubernetes_api_server_audit
  - helm_release_events
  - terraform_cloud_state
trigger:
  - event: k8s.rbac.create OR k8s.rbac.update
  - resource: ClusterRoleBinding OR RoleBinding
  - condition: |
      binding.role == "cluster-admin"
      OR role.rules[].verbs.includes("*")
      OR role.rules[].resources.includes("secrets")
      AND actor NOT IN [known_iac_service_accounts, system_components]
enrichments:
  - iac_correlation: terraform_run_id, helm_release_id
  - service_account_usage: currently_mounted_in_pods
  - post_escalation_activity: k8s_api_calls_15m
  - opa_policy_gap: gatekeeper_admission_bypass
mitre: T1078.001 (Valid Accounts: Default Accounts), T1548 (Abuse Elevation Control)

Triage agent questions

Was a ClusterRoleBinding created that grants cluster-admin to a service account or user?

K8s audit log

Is the service account receiving elevated permissions used by a running workload or orphaned?

Kubernetes API

Did the RBAC change come from a CI/CD pipeline run or an interactive kubectl session?

Audit user agent

Was there a corresponding Terraform or Helm change that should account for this RBAC modification?

IaC pipeline

What API calls has the affected service account made in the last hour?

K8s API server audit

Are there other unusual RBAC changes in the cluster in the past 24 hours?

Audit correlation

Response playbook

Capture the full RBAC diff (before/after) for forensic documentation

Autonomous

Alert the platform engineering team and request change justification

Autonomous

If no linked pipeline run found: revoke the excessive permission immediately

Approve-gated

Audit all API calls made by the over-privileged service account in the change window

Autonomous

Implement OPA/Gatekeeper policy to prevent future wildcard ClusterRoleBindings

Recommend

MITRE ATT&CK mapping

T1078.001 — Valid Accounts: Default AccountsT1548 — Abuse Elevation Control MechanismT1613 — Container and Resource Discovery

Kubernetes RBAC abuse FAQ

What Kubernetes RBAC patterns does ManySignal consider high risk?

Wildcard verb grants (verbs: ['*']), ClusterRoleBindings for non-system service accounts, grants to the default service account in production namespaces, and any binding that grants create/patch/delete on secrets, pods/exec, or ClusterRoles. Each pattern has a dedicated detection rule.

Does ManySignal monitor RBAC in all namespaces simultaneously?

Yes. ManySignal connects to the Kubernetes API server audit log, which captures all namespace-scoped and cluster-scoped RBAC operations. Multi-cluster environments are supported — each cluster's audit log is ingested independently and correlated via the entity graph.

Can ManySignal prevent RBAC changes rather than just detect them?

Prevention is handled through OPA/Gatekeeper or Kyverno policies that ManySignal can generate and deploy as recommended actions. Detection covers changes that bypass or precede policy installation. The combination of preventive and detective controls is the recommended architecture.

Does this integrate with tools like Kubescape or Starboard?

Yes. ManySignal ingests RBAC posture findings from Kubescape (ARMO) and Trivy Operator. These finding are enriched with runtime context — which service accounts are actively being used and by what workloads — to prioritize remediation.

Monitor Kubernetes RBAC changes in real time

K8s audit log correlation with IaC attribution and post-escalation activity tracking.

Book a demo Explore the platform