Service-Account Token Signing in Kubernetes

Abstract

At any time, one active signing authority signs every new service-account token in a Kubernetes cluster. Whoever obtains that key can mint tokens that authenticate as any service account, offline and without contacting the cluster; authorization and admission control then evaluate those requests under their normal rules. Bound tokens, short lifetimes and RBAC limit what a stolen token can do, but none of them limits what a stolen signing key can do. We systematize service-account token signing in Kubernetes. We review the authentication mechanisms and the mitigations deployed around them, organize signing designs into four architectures (an in-tree key, an external signer backed by an HSM or KMS through KEP-740, a parallel workload-identity system, and threshold signing), and compare them under a unified threat model. The central result is the distinction between offline forgery, which threshold signing prevents below the threshold, and online misuse, which it does not: an attacker who controls the coordinator can obtain tokens whose claims the signers’ policy accepts, which under a realistic policy include privileged kube-system accounts (by an escalation path we derive from Kubernetes source but do not execute), because signers can check claims but not whether issuance was authorized. We map the design space behind KEP-740. In Kubernetes v1.36.5 the immediate verifier-level blocker for FROST is the absence of EdDSA from the algorithm allow-list, although FROST’s Ed25519 ciphersuite produces standard Ed25519 signatures; implementation maturity and key generation are separate questions. Four illustrative compromise models show that signer independence, not the size of the threshold, bounds the benefit. A documentation survey of five self-managed distributions and three managed services finds that all five distributions keep the key on control-plane nodes or in the cluster’s datastore, that one of the three managed services offers a customer-managed signing key, and that cloud federation can make the key a cloud credential. We close with a decision framework and open problems.