Rory McCune@shodan Just wondering, are there any plans at your end to update the Kubernetes scan data you've got? At the moment searches like https://www.shodan.io/search/facet?query=product%3A%22Kubernetes%22&facet=version are pretty out of date, it'd be cool to see the up to date picture!
Shodan@raesene we continuously scan for it and all of those results are recently collected. The version information is fetched from the K8s service itself.
@shodan I think that perhaps that version information isn't getting updated properly. What I'm seeing on that facet is like the attached screenshot which is showing the latest version as 1.22 but that version has been unsupported by any provider for a while now (well over a year.) The current latest version of Kubernetes is 1.34 and most providers are only offering 1.28 or higher.
Also from a blog I did looking at Datadog's customer versions https://securitylabs.datadoghq.com/articles/a-2025-look-at-real-world-kubernetes-adoption/ we're seeing most clusters being at v1.28 or higher as well...
@raesene thanks for the clarification. it does look like the response from k8s changed in recent versions in subtle ways that caused our crawlers to not check the /version URL for those newer deployments. We're deploying a fix for that atm! Note that Shodan doesn't scan in sweeps. We constantly crawl the Internet (https://data-status.shodan.io) and then perform additional metadata collection based on the responses.
@raesene already starting to see a shift: https://www.shodan.io/search/facet?query=product%3Akubernetes+after%3A11%2F12%2F2025&facet=version thank you for reaching out about this!
@shodan Awesome, yeah that's looking good!
@shodan BTW one other thing that could be useful for Identifying Kubernetes clusters is that pretty much every Kubernetes API server has some distinctive values in the Subject Alternative Names field. For example "kubernetes.default.svc.cluster.local" will be there as it's used internally by services to connect to the API server.
This helps catch places where /version is blocked (for example Microsoft AKS)
@raesene yup, we do look at those sorts of artifacts to identify K8s and then if those are found we try to do the /version request. there might be more we can do but we do identify ones in azure: https://www.shodan.io/search?query=product%3Akubernetes+cloud.provider%3Aazure
Nice! yeah seeing the exposed 10250's for the Kubelet is interesting there as that's not a default so I guess customers are exposing their Node interfaces for $reasons...
I have a feeling that you might get some more hits with a combination of 443/TCP and the hostname I mentioned in the SAN field, just as those are default settings for standard AKS clusters, but then they don't contribute to the version info as they're blocking that endpoint.