KUBERNETES

Kubernetes 1.37 Pod Certificates and SPIFFE: Similar ideas, different layers



Kubernetes 1.37 introduced two features that immediately caught my attention: Pod Certificates and ClusterTrustBundles. ( https://kubernetes.io/blog/2026/08/28/kubernetes-v1-37-pod-certificates-and-cluster-trust-bundles/ )

If you are familiar with SPIFFE and SPIRE, some of this will sound surprisingly familiar. Short-lived certificates for workloads, automatic certificate rotation, istribution of trusted CA certificates…

First thing that came to my mind was whether Kubernetes is starting to build its own version of SPIFFE. There is definitely overlap, but the two systems are solving different layers of the workload identity problem.

Extending kubectl



*Kubectl Plugin*

As you probably already know, kubectl is the official tool to interact with Kubernetes from the command line. This tool, besides all the functionality that it already provides, allows us to extend its functionality through plugins.

A kubectl plugin is nothing but a file with the following three requirements:

• It has to be an executable (binary or script)
• It must be in your system’s PATH
• Its name must start with kubectl- (including the dash!)

The plugin system in kubectl was introduced as alpha in version 1.8.0 and it was rewritten in version 1.12.0, which is the minimum version recommended if you are going to play with this feature.

How kubectl uses Kubernetes API



*kubectl Fuente: https://blog.risingstack.com/what-is-kubernetes-how-to-get-started/*

As you probably already know, any type of query or command that you run against Kubernetes , it is done by sending an API request to a component called API server. This component lives in the master node/s.



*Fuente: https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/*

The most common way to interact with a Kubernetes cluster, although you have several graphical options, it is through a command line tool called kubectl.