Threshold-Signed Service-Account Tokens for Kubernetes

Abstract

At any time, one signing key signs every new service-account token in a Kubernetes cluster, and a copy of it lets an attacker mint tokens offline for any identity. We present an external signer that removes that key: it plugs into the stable ExternalJWTSigner interface (KEP-740) and produces each RS256 token signature by combining shares from three of five signers with Shoup threshold RSA, so that no process holds the complete key after key generation. An unmodified kube-apiserver v1.36.5 accepts its tokens. We report three results. First, the design: why FROST could not be used, how signers enforce their own claims policy, how the coordinator verifies shares optimistically with a breaker, and how signers admit work only if it can finish before the caller’s deadline. Second, the measured cost on a kubeadm cluster on AWS, against the in-tree signer and a single-key external signer on the same path: about 21 ms more per token with signers in one region and about 149 ms across five regions, a throughput plateau near 70 tokens/s bounded by signer CPU, and no measurable slowdown when scaling to 200 pods. Third, a failure mode specific to threshold services: when CPU-capped signers shed load independently, many requests collect fewer than three shares, and 29–47% of the shares computed are wasted on requests that fail. Two admission-control designs adapted from microservice overload control were tested against rules fixed before their data; neither met its rules, and the second revealed a trade-off between sustained overload and retry storms. We report these results as measured, including the negative ones, with an audited, reproducible artifact.