clastix/kamaji

What I am trying to do Rotate a TenantControlPlane's ServiceAccount signing key without invalidating every projected token in the tenant at once. kube-apiserver already separates the two jobs: --service-account-key-file — what it will verify. Repeatable (StringArray), and one file may hold several PEM keys. --service-account-signing-key-file — the single key it signs with. So a safe rotation is three moves: widen the verify list to old+new, switch signing to new, and after the longest live token TTL drop the old key. At no point is a live token refused. What happens today Deleting <tcp>-sa-certificate and letting Kamaji regenerate is a hard rotation: the API server returns signing and verifying with one new key, so every existing projected token is refused immediately. On our tenant that took out CoreDNS and the konnectivity agents — both authenticate with projected tokens — and with in-cluster DNS gone, workloads could not resolve anything. Recovery took 26 minutes, unattend

Summary Certificate/TLS hardening findings in internal/crypto/crypto.go and internal/datastore/datastore.go. None is remotely exploitable on its own; these are least-privilege / robustness improvements. Findings 1. Client-auth certificate gets overly broad Extended Key Usages (Medium) internal/crypto/crypto.go:269-273 NewCertificateTemplate (used for etcd client authentication, datastore_certificate.go:143) sets ExtKeyUsage to ClientAuth, ServerAuth and CodeSigning. For a pure client-auth certificate, ServerAuth/CodeSigning are unnecessary. The subject organization is also system:masters (line 264), i.e. a highly privileged etcd identity — if the key leaks it is additionally abusable as a server cert and for code signing. Fix: restrict EKU to x509.ExtKeyUsageClientAuth. 2. Certificate serial number from math/rand; static SubjectKeyId (Low) internal/crypto/crypto.go:16,261,268 SerialNumber: big.NewInt(mathrand.Int63()), SubjectKeyId: []byte{1, 2, 3, 4, 6}, math/rand is non-cryptograph

Summary Correctness and resource-safety bugs in the relational datastore drivers (internal/datastore/mysql.go, postgresql.go). Two of the original four findings are fixed, verified against master 0203099: MySQL migration switches to namespace_name instead of the configured schema — fixed in #1239: mysql.go:78 and :110 use tcp.Status.Storage.Setup.Schema, quoted. GrantPrivilegesExists leaks a connection on the match path — fixed in #1221: the Query and row loop became a single QueryRowContext(...).Scan(...), so there is no rows to leak and the //nolint:sqlclosecheck is gone. The two below are still present. I re-checked both against the library sources and corrected the original descriptions — the first was mis-attributed as a data race, the second was overstated. 1. PostgreSQL: switchDatabaseFn mutates the root connection's options internal/datastore/postgresql.go:113-118 fn := func(dbName string) *pg.DB { o := opt // copies the pointer, not the struct o.Data