Kubernetes has introduced Pod Certificates and Cluster Trust Bundles as a new production identity mechanism. This feature, now generally available, integrates X.509 certificate issuance for TLS and mTLS directly into core Kubernetes. This is a significant step beyond the previous primary mechanism, service account JWTs. While JWTs offer ease of use and broad compatibility, they suffer from a crucial weakness: they are bearer tokens, making them susceptible to unauthorized access if compromised. Pod Certificates, on the other hand, leverage proof-of-possession credentials based on asymmetric cryptography, primarily X.509 certificates. This enhances security by requiring a demonstration of possession rather than simply sharing the credential itself.The goal is to make using X.509 certificates from Kubernetes workloads as straightforward as JWTs while maintaining high security standards. Pod Certificates are designed for flexibility, allowing for various certificate types within a single cluster through a pluggable interface. This contrasts with the single, standardized flavor of service account JWTs. Future Kubernetes versions are expected to offer built-in certificate providers for service DNS names and SPIFFE client certificates.The architecture involves the application requesting certificates, Kubelet issuing requests and managing trust bundles, and a signer controller fulfilling these requests and publishing trust bundles. The issuance process is chronological, starting with the pod's scheduling and culminating in the application accessing its keys and certificates. Automatic rotation is built-in, with applications needing to handle these updates. Security checks are integrated into the kube-apiserver to enforce isolation and prevent compromised nodes from gaining undue access. To experiment with these features, users need to install a third-party signer like Tinycert, which provides example signers and a library to help applications load SPIFFE certificates.