← Problem Library
K8s L6 K8S 1363 · 15 min

A webhook certificate is valid and admission still times out

Pods can access the webhook, yet admission fails because the control-plane source path was never whitelisted in the same way.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A team validates a webhook from test pods and later still gets admission timeouts after a policy hardening change.

What to check first
  • Identify the primary failure signal in the Pods Could Reach the Webhook and the API Server Took a Different Network Path scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Test control-plane reachability directly before changing certificates or webhook readiness.

Questions worth viewing together
What should you verify first when A webhook certificate is valid and admission still times out appears?

Community-field Kubernetes problem inspired by admission-webhook discussions where pod tests passed but the apiserver path was blocked. Webhook health from pods does not prove the apiserver can reach the same endpoint.

What usually causes A webhook certificate is valid and admission still times out in production?

Teams often blame TLS when the control-plane network path is what the policy actually blocks.

What should you document after resolving A webhook certificate is valid and admission still times out?

Admission webhook policy should explicitly account for apiserver source paths, not just workload traffic.