4 ms·

Yea the RBAC part is tricky. I think you need PAM or some sort of agent on the hosts to do that if you need individual user accounts (vs "principal" accounts th

Yea the RBAC part is tricky. I think you need PAM or some sort of agent on the hosts to do that if you need individual user accounts (vs "principal" accounts that map to server groups like "frontend", "backend", "database"). The latter isn't a terrible option when you use certs, fwiw, since you can still get good audit by encoding the actual user in the certificate, which gets logged to `auth.log`. Still, not ideal for everyone. This is one of a handful of problems we're working to solve / streamline for an SSH product. We might even open source this bit, but not sure yet. If we don't, it still probably wouldn't be $hundreds/$thousands per month unless you have a huge org. If you're interested at all I'd love to talk more about this -- what your requirements are, whether you want hosted/not hosted, whether you want to pay at all / how much you'd be willing to pay, etc. Easiest thing to do to stay in the loop is send us your email at https://smallstep.com/sso-ssh/ https://smallstep.com/sso-ssh/ by "requesting early access" and we'll reach out to schedule a convo & keep you updated as we make progress. Or just watch our blog! :)

rob-olmos 7y ago
Thanks for your reply and offer. I'll look into the product a bit more when I get some free time. I think I was a bit vague about RBAC. I'm thinking that the user account creation isn't vital in this use case since the audit log holds who generated/access. It's more about controlling who can generate a cert for what. Eg, I think Teleport's model has the RBAC config at or near the CA part, so the cert generation either happens if authorized or denied if not.
- mmalone 7y ago
  Oh, our open source stuff has basic controls around that... using OAuth OIDC you can only get a certificate for yourself (right now it's just a direct mapping so it goes from, e.g., mike@example.com to just `mike` as the principal in the cert). For hosts our instance identity document stuff for cloud VMs can be configured to only issue certificates for the VMs hostname. Or at least it should be able to do that. I think there's a bug we're currently working on. We also have a one-time-token mechanism that you can have some trusted infra like Puppet issue to hosts as they come up. The token includes the specific name that you want bound in the cert. It can only be exchanged for a cert with that subject. Super secretly: we also have a whole policy language and enforcement engine that we'll eventually get around to doing something with and would address this issue pretty comprehensively. Edit: After reading your comment again I think I still might be misunderstanding your use case. Are you talking about having principals like "frontend" and "backend" and then having RBAC that says "mike can get a cert for frontend"?

rob-olmos 7y ago

Thanks for your reply and offer. I'll look into the product a bit more when I get some free time. I think I was a bit vague about RBAC. I'm thinking that the user account creation isn't vital in this use case since the audit log holds who generated/access. It's more about controlling who can generate a cert for what. Eg, I think Teleport's model has the RBAC config at or near the CA part, so the cert generation either happens if authorized or denied if not.

mmalone 7y ago
Oh, our open source stuff has basic controls around that... using OAuth OIDC you can only get a certificate for yourself (right now it's just a direct mapping so it goes from, e.g., mike@example.com to just `mike` as the principal in the cert). For hosts our instance identity document stuff for cloud VMs can be configured to only issue certificates for the VMs hostname. Or at least it should be able to do that. I think there's a bug we're currently working on. We also have a one-time-token mechanism that you can have some trusted infra like Puppet issue to hosts as they come up. The token includes the specific name that you want bound in the cert. It can only be exchanged for a cert with that subject. Super secretly: we also have a whole policy language and enforcement engine that we'll eventually get around to doing something with and would address this issue pretty comprehensively. Edit: After reading your comment again I think I still might be misunderstanding your use case. Are you talking about having principals like "frontend" and "backend" and then having RBAC that says "mike can get a cert for frontend"?