More Info:
Verifies that the API server —request-timeout argument is set appropriately to limit how long requests may run and protect against slow or hung connections.Risk Level
MediumAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Gather current configuration (each control plane node)
- Confirm whether
--request-timeoutis present and note its value (or absence).
- Confirm whether
-
Review cluster usage and risk tolerance (any machine with access to cluster context/info)
- Identify workloads that legitimately run long API operations (e.g., large list/watch, bulk custom resources, aggregating APIs).
- Discuss with app and platform owners what an acceptable upper bound is for API request duration vs. user-facing timeouts and SLAs.
-
Decide on an appropriate timeout value
- Use a finite value; typical ranges:
60s–300sfor general-purpose clusters. - Choose a higher value only if you have known, legitimate long-running API calls and can tolerate the associated resource usage and DoS risk.
- Record the chosen value (for example
300s) in your ops/runbook documentation.
- Use a finite value; typical ranges:
-
Update the kube-apiserver static pod manifest (each control plane node)
Edit the manifest:In thecommand:(orargs:) list forkube-apiserver, add or adjust one line such as:- Ensure there is exactly one
--request-timeoutentry. - Save the file; the kubelet will automatically restart the API server pod (control plane impact: brief API unavailability during restart).
- Ensure there is exactly one
-
Verify the new setting (each control plane node)
After the API server pod is back inRunningstate:- Confirm the running process shows the intended
--request-timeoutvalue.
- Confirm the running process shows the intended
-
Monitor for side effects (any machine with kubectl access)
- Watch for client-facing timeouts or failed long-running operations:
- If legitimate operations are being cut off, repeat steps 2–5 to adjust the timeout to a better-fitting value.
- Watch for client-facing timeouts or failed long-running operations:
Using kubectl
Using kubectl
kubectl cannot modify the API server’s --request-timeout flag because it is configured on the host in the static pod manifest /etc/kubernetes/manifests/kube-apiserver.yaml on every control plane node. To address this finding, follow the guidance in the Manual Steps section on each control plane node.Automation
Automation

