talosctl gen secrets generates ECDSA rather than RSA service account signing key

[willglynn]

talosctl gen secrets produces an ECDSA signing key for Kubernetes service account authentication:

% talosctl gen secrets; yq .certs.k8sserviceaccount.key secrets.yaml | base64 -d; rm secrets.yaml
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBFkwZNtMWiJjugGzhc0T+Zxqp+xQ7debBJLnjq8+AMdoAoGCCqGSM49
AwEHoUQDQgAEgkV10TqVebZCw9KXJ+XfCT7dZ5NNTFC8wEZdZ4i2iWJSM/2F17WQ
EuHsGo4Bf5IfqH/RS3GCam8ZoXCs7J36rA==
-----END EC PRIVATE KEY-----

Typical install processes plumb this key into v1alpha1 cluster.serviceAccount.key, which eventually finds its way (1, 2) into kube-apiserver --service-account-signing-key-file:

--service-account-signing-key-file string
    Path to the file that contains the current private key of the service account
    token issuer. The issuer will sign issued ID tokens with this private key.

I propose changing the service account signing key from ECDSA to RSA. The Kubernetes API server supports signing and verifying both kinds of keys, but they are not functionally equivalent, and overall ECDSA is less supported than RSA.

If the Kubernetes API server supports both, what does it matter? Kubernetes 1.21 added OpenID Connect discovery support allowing external entities to validate service account tokens. This is useful because external systems can establish trust relationships directly to cluster service accounts without requiring shared secrets. The service account documentation hints at some caveats:

Note: The responses served at /.well-known/openid-configuration and /openid/v1/jwks are designed to be OIDC compatible, but not strictly OIDC compliant. Those documents contain only the parameters necessary to perform validation of Kubernetes service account tokens.

OIDC Discovery spec § 3 spells out one such caveat:

id_token_signing_alg_values_supported
REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. The algorithm RS256 MUST be included. The value none MAY be supported but MUST NOT be used unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow).

Kubernetes service tokens conform to the letter of the OpenID Connect specification if and only if the service account signing key is RSA.

Beyond the spec, RS256 JWTs enjoy significantly better compatibility than ES256 across the JWT/OIDC ecosystem. Major issuers like google.com and facebook.com produce only RS256 tokens. Anecdotally, I have encountered several implementations which support RS256 and not ES256 but none the other way around.

One concrete use case is that AWS can be configured to trust arbitrary OIDC issuers, and this is commonly used with Kubernetes clusters via IAM Roles for Service Accounts. However, authenticating to AWS using a JWT specifically requires an RS256 token, thus requiring that the Kubernetes cluster use an RSA service account signing key.

Would you accept a PR changing Talos secret generation?

[smira]

I'm not sure if that should be the default choice, or whether it should be configurable. ECDSA is also way faster than RSA, which is important e.g. for SBCs

[smira]

But being compatible with some common OIDC providers makes sense as well