4 ms·

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.

by zxcmx 7y ago

raesene9 7y ago
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...
- zxcmx 7y ago
  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.
- zxcmx 7y ago
  As an aside, if you want revocable, non expiring user creds you would be better served by bearer tokens.
  - raesene9 7y ago
    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.
throwaway_se099 7y ago
With certs that short-lived, you're just reinventing Kerberos, badly.
- zxcmx 7y ago
  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.

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.

by zxcmx 7y ago

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.

raesene9 7y ago

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...

zxcmx 7y ago
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.
zxcmx 7y ago
As an aside, if you want revocable, non expiring user creds you would be better served by bearer tokens.
- raesene9 7y ago
  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.

throwaway_se099 7y ago

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

zxcmx 7y ago
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.