If you issue user certs, it is best to do it from software and have them live for 8h max.

Also recommended: keep api behind a jumpbox.

I've seen short-lived certs as a suggested workaround for the lack of revocation and as a user that might be the best option.

That said the distributions I've seen that make use of client certs, don't do that (typical lifetime for a client cert is 1 year), so I'm guessing a load of people using k8s will have these certs floating about...

It’s a mental shift similar to using iam assume role sessions rather than static keys with perms right on em.

Powerful creds should be limited in lifespan and machine issued to users in a transaction that involves mfa.

We built our own but Gravitational Teleport I think has these patterns in a product.

The other issue even if you get certs right is service tokens (an admin could have grabbed a copy of one and they can be used from outside cluster) so want to keep that api wrapped IMHO.

As an aside, if you want revocable, non expiring user creds you would be better served by bearer tokens.

True, the only real in-built option in k8s land for that is Service accounts, which aren't designed for user auth. but can be used for that purpose.

With certs that short-lived, you're just reinventing Kerberos, badly.

Using a similar pattern (tickets I guess) doesn’t mean you’re reinventing something.

You might equally say we’re reinventing “authenticated sessions”. More in common with jwt cookies tbh.

We don’t want to run krb infrastructure so we don’t do that.

The runtime dependency on ldap or NIS, plus keeping krb itself HA, fed and happy plus OS dependent PAM setup make krb fairly undesirable in a production cloud environment if ssh certs and kube certs would suffice.