urllib3 2.4.0 + Python 3.13 breaks SSL against Kubernetes: what you need to know

Bumped to Python 3.13 and suddenly your Kubernetes automation stopped working? Here’s the error you’re probably seeing:

urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='xxxx.gr7.us-east-1.eks.amazonaws.com', port=443):
Max retries exceeded with url: /version/
(Caused by SSLError(SSLCertVerificationError(1,
'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
Missing Authority Key Identifier (_ssl.c:1028)')))

Nothing changed on the cluster side. The problem is on your machine — specifically the combination of Python 3.13 and urllib3 2.4.0. Tracked in kubernetes-client/python#2394.

What’s actually going on

Python 3.13 made SSL certificate validation stricter. urllib3 2.4.0 followed. Together they now reject certificates that are missing an Authority Key Identifier field.

Kubernetes API server certificates generated on version 1.16 or earlier didn’t include this field — it just wasn’t part of the cert generation at the time. So any cluster whose API server certificate was issued back then and hasn’t been rotated since will hit this. Not just EKS — self-managed clusters, GKE, AKS, anyone in the same boat.

The fix is coming from the Python client side (PR #2417), not from the clusters.

One thing that makes this tricky to diagnose: curl, kubectl, and openssl all continue to work fine. Only Python 3.13+ clients fail. So your cluster looks healthy, but your automation breaks — which can be confusing.

Are you affected?

You need all three at the same time:

• Python 3.13
• urllib3 >= 2.4.0
• Python code talking to the Kubernetes API

Still on Python 3.12? You’re fine, nothing to do. Java workloads like Keycloak, Kafka, or Spring apps are also completely unaffected — this is Python-only. And upgrading EKS to 1.33 doesn’t change anything here either.

Workarounds

Option 1 — pin urllib3 (safest, recommended):

urllib3<2.4.0

Or in pyproject.toml:

[tool.poetry.dependencies]
urllib3 = "<2.4.0"

Option 2 — skip TLS verification (teams are using this in production as a stopgap):

SKIP_TLS_VERIFY=true

Or in the Python kubernetes client directly:

configuration.verify_ssl = False

This works but is not great — you lose certificate validation entirely. Use it only as a short-term measure while you sort out the proper fix, and never in internet-facing environments.

How much time do you have?

If you’re on Python 3.12 you have plenty of runway before this becomes relevant:

About 2.5 years on 3.12 before you need to think about this. When you do move to 3.13, just make sure kubernetes-client has the fix from PR #2417, or keep the urllib3 pin in place.

What about the cluster side?

The real permanent fix would be certificate rotation — updating the EKS root CA to include the missing Authority Key Identifier and Subject Key Identifier extensions. AWS is tracking this as a feature request in the EKS public roadmap (containers-roadmap#2638). If you’re affected and want to push for it, upvoting that issue helps signal priority to the team. No timeline yet.

GKE users are in the same position. The urllib3 issue (urllib3#3614) has reports of GKE clusters with 4-year-old certificates hitting the exact same error. This is a broad ecosystem problem, not specific to any one cloud provider.