OpenShift Limitrange Explained¶

Introduction¶

ResourceQuota and LimitRange protect shared OpenShift projects from uncontrolled consumption. They also explain many pod admission failures when requests or limits are missing.

Why This Matters¶

OpenShift adds security defaults such as SCCs, project isolation, and integrated OAuth/RBAC behavior. These protections are useful only when permissions are granted narrowly and verified.

Step-by-Step Configuration¶

oc get resourcequota -n app

oc describe resourcequota compute-quota -n app

oc get limitrange -n app

oc describe limitrange default-limits -n app

Example output:

NAME            AGE   REQUEST                                  LIMIT
compute-quota   3d    requests.cpu: 800m/2, requests.memory: 1Gi/4Gi

Verification¶

oc describe resourcequota compute-quota -n app

oc describe limitrange default-limits -n app

oc get events -n app --sort-by=.lastTimestamp

Security Best Practices¶

Grant the smallest role or SCC that works, prefer service-account-specific access, keep secrets out of Git, and verify permissions with oc auth can-i.

Common Mistakes¶

• Adding quotas without communicating default limits.
• Debugging Pending pods without checking quota events.
• Setting CPU limits globally without considering throttling.

Troubleshooting¶

Compare the failing user or service account with the role binding, SCC admission error, project quota, or OAuth status shown in OpenShift events.

Related Guides¶

• Openshift Security Context Constraints Explained
• Openshift RBAC Security Explained
• Openshift Security Checklist

Summary¶

OpenShift Limitrange Explained is safest when permissions are explicit, namespace-scoped where possible, and validated from the same identity that runs the workload.