Wiz Introduces NamespaceHound to Assess Kubernetes Tenant-Isolation Risks
Summary
Wiz’s NamespaceHound analyzes Kubernetes clusters for potential cross-namespace access paths and anonymous access. The article also outlines practical controls for strengthening tenant isolation.
Key points
- NamespaceHound analyzes a Kubernetes cluster for possible paths across namespace security boundaries; operators can also scope analysis to one namespace.
- The tool checks for anonymous access opportunities and can identify issues such as service accounts able to read secrets or create workloads in another namespace.
- NamespaceHound requires read permissions across all resource types and queries the cluster API; Wiz says it does not save cluster data locally.
- The CLI supports kubeconfig input, table, JSON, CSV, or HTML output, and a control-plane check for kube-system.
- The article recommends least-privilege RBAC, avoiding tenant assignments to global administrators, and using admission controls to restrict risky workloads.
- It also recommends network policies to block unwanted cross-tenant traffic and disabling automatic service-account token mounting when API access is unnecessary.
- Additional isolation measures include tenant-specific storage configuration, isolated external-secret access, and careful review of globally scoped resources.
Article Details
- Defense Focus
- Assess and strengthen namespace isolation in multi-tenant Kubernetes clusters, identifying cross-namespace access paths and anonymous access opportunities.
- Detection Methods
- Run NamespaceHound against a cluster to analyze possible paths across namespace security boundaries.
- Use the optional namespace parameter to focus analysis on paths from a specified namespace, including anonymous access.
- Review RBAC permissions for cross-namespace access to secrets and workload creation.
- Inspect the potential blast radius and namespace-crossing opportunities shown in the Wiz portal's Kubernetes namespace Forensics section.
- Data Sources
- Kubernetes API server queries
- Kubernetes RBAC API
- Cluster configuration and resource permissions
- Platforms
- Kubernetes
- Defensive Actions
- Grant tenant principals only namespace-level Roles, not global administrator roles; follow least privilege and avoid wildcard verbs or resources.
- Use admission controls to restrict privileged pods, root-running pods, and pods using the default service account.
- Avoid sharing globally scoped resources across tenants, or protect them with dedicated ClusterRoles.
- Use separate StorageClasses per tenant; if a StorageClass is shared, set the PersistentVolume reclaim policy to Delete.
- Isolate external secret-storage access per tenant.
- Disable automatic service-account token mounting when pods do not need API-server communication.
- Apply Kubernetes Network Policies to block cross-tenant and tenant egress connectivity, using namespace labels where appropriate.
- Consider node affinity to schedule tenant workloads onto assigned worker nodes.