More Info:
Advisory: create a ResourceQuota per tenant namespace to bound aggregate CPU, memory and object counts, preventing one tenant from starving others.Risk Level
LowAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify tenant namespaces (decision step)
On any machine with kubectl access, list namespaces and decide which are “tenant” namespaces (per your org’s multi-tenancy model; usually app or team namespaces, notkube-*,default, or system namespaces):Optionally, if you label tenant namespaces (recommended), e.g.tenant=true, list them: -
Check which tenant namespaces lack a ResourceQuota
For each tenant namespace you identified, check for existing ResourceQuota objects:Note which tenant namespaces returnNo resources foundor have quotas that clearly do not bound CPU, memory, and object counts. -
Review existing ResourceQuota coverage and sufficiency (decision step)
For tenant namespaces that do have a ResourceQuota, inspect them to ensure they bound at least aggregate CPU, memory, and key object counts (e.g. pods, services, PVCs, configmaps, secrets):Decide whether limits are appropriate for the tenant (not too low to break workloads, not so high that tenants can starve others). -
Design quota policies per tenant type (decision step)
Outside the cluster (on any admin workstation), define standard quota “profiles” for different tenant types (e.g. small/medium/large) that include:requests.cpu,requests.memory,limits.cpu,limits.memorypods,services,persistentvolumeclaims,configmaps,secrets, etc.
Document which profile each tenant namespace should receive based on current and projected usage.
-
Create or update ResourceQuota manifests for tenant namespaces
On any machine with kubectl access, create or adjust ResourceQuota objects according to your profiles. Example manifest (adjust values per your decisions):Apply for each tenant namespace (edit the manifest namespace or generate one per namespace): -
Verify quotas are in place and effective
On any machine with kubectl access, confirm that every tenant namespace now has an appropriate ResourceQuota and that usage is tracked:Re-run this check for all tenant namespaces; any tenant namespace without a ResourceQuota, or with quotas that don’t bound CPU, memory, and object counts, should be revisited using steps 3–5.
Using kubectl
Using kubectl
kube-system, kube-public, kube-node-lease, istio-system, ingress-nginx, etc.).- If this command returns
No resources found in TENANT_NS namespace, the tenant namespace has noResourceQuotaand is in violation of this control. - If it returns one or more
ResourceQuotaobjects, you must still review them (next step) to decide whether the quotas are adequate.
Hardlimits missing for CPU or memory (e.g. no entries forlimits.cpu,limits.memory,requests.cpu,requests.memory) mean aggregate resource usage is not bounded.- Missing object count limits (e.g.
pods,configmaps,secrets,services,persistentvolumeclaims) mean the namespace could still starve others via object count exhaustion. - Very high or effectively unlimited values (e.g.
0where that means “no limit”, or values that exceed node/cluster capacity) indicate quotas are not meaningfully constraining the tenant.
- Any tenant namespace that does not appear in this list lacks a
ResourceQuotaand should be reviewed and corrected. - Namespaces that appear with quotas but you know are not tenants (e.g. system namespaces) are not relevant to this control and can be ignored.
Automation
Automation
- In the CSV section, any row where the second column (
HasResourceQuota) isNOindicates a tenant namespace that does not have anyResourceQuotaobjects defined. - The final summary line
Namespaces without any ResourceQuota: N:- If
N > 0, those namespaces are not constrained and should be reviewed and given an appropriateResourceQuotaper the benchmark guidance.
- If

