|
|
|
|
|
by ropman76
2574 days ago
|
|
"After several years of trying to manage these issues with Kerberos, we decided to redesign the system from the ground up.."
I am curious, is there anyone who went the opposite direction direction and implemented a new Kerberos library or setup? |
|
For example, OSKT is a self-service toolkit that lets users build up access controls for clusters, "role accounts" (user accounts for running application automation), and what not. Users use "krb5_prestash" to indicate what hosts should have what role accounts' credentials (the user must own the hosts and role accounts) and krb5_keytab to get keys for services on hosts they are allowed to run. A nifty trick is to have wildcard DNS A RRs for hosts so that one can have HTTP/${USER}.$(uname -n) principals (and keys for them) on any host the user can login to.
All of this is high-performance and self-service. Users don't need to file JIRA tickets or whatever to get their keys for their services.
Self-service credential provisioning is absolutely essential to successful deployment at scale of any authentication system one uses, whether that be Kerberos or PKIX or DANE or anything else one might find or invent.