Skip to main content

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

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Gather current configuration (each control plane node)
    • Confirm whether --request-timeout is present and note its value (or absence).
  2. 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.
  3. Decide on an appropriate timeout value
    • Use a finite value; typical ranges: 60s300s for 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.
  4. Update the kube-apiserver static pod manifest (each control plane node)
    Edit the manifest:
    In the command: (or args:) list for kube-apiserver, add or adjust one line such as:
    • Ensure there is exactly one --request-timeout entry.
    • Save the file; the kubelet will automatically restart the API server pod (control plane impact: brief API unavailability during restart).
  5. Verify the new setting (each control plane node)
    After the API server pod is back in Running state:
    • Confirm the running process shows the intended --request-timeout value.
  6. 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.
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.