Simple authorization support

[copumpkin]

At the highest level, my goal is for different hologram users to have different access to different roles.

I don't know of the best way to do this, but off the top of my head, we could have a custom LDAP property that lists ARNs of roles the particular user is allowed to assume. Ideally the system would also be group-aware, and a user's access would be the union of the ARNs associated with the user's groups and the user's own special access.

Then, I think I would just type hologram use arn:aws:iam::123456789012:role/mytest (being able to enter full ARNs is nice for cross-account access) and have it just work.

Is anything blatantly wrong with this? Can it be done more cleanly? Does it seem like the sort of thing that belongs in hologram?

[gaylatea]

Hello Daniel, thank you for reporting these issues and pointing out various ways we can improve Hologram. I actually had a JIRA ticket filed to investigate this, but didn't have the time before we pushed the open-source release out. 😺

It's a fantastic idea, and certainly the type of thing that belongs in Hologram, especialy if we want a larger audience for the system. A couple thoughts on this:

• The hologram use invocation you mention can be shortened dramatically. hologram use 123456789012/mytest would be sufficient for the cross-account use case, and hologram use mytest would continue to work as the default account case. Little use in making people type out full ARNs when only two parts of it matter. Good idea, though.
• The LDAP integration for this will be tricky. As Hologram is configured (on recommendation from the IAM team), individual users do not necessarily have IAM accounts associated with them. Indeed, IAM accounts are really only useful for people who also have console access. My planned usage was that the Hologram server would search for accounts with the same name as the user's cn. If found, they would do the user/group union permissions you mention and apply that to the "developer" role you create. I think this would work, too.

Ideally I would like to keep as little information in LDAP as I can, and push functionality to the IAM APIs. LDAP is already hard enough to administer, and AWS has built-in stuff for most of this. Tricky part is getting a nice, user-friendly face on it.

You're definitely onto something. Interested to hear more thoughts.

[copumpkin]

Sorry for my delayed response!

I definitely agree with your hologram use point, and think that would be nice and fairly easy.

About the authorization/LDAP point, I see where you're coming from but I also find it fairly appealing to manage user access in the LDAP server (where many other permissions for other services can be granted/revoked). For example, I'd love to just be able to add someone to a group in my directory and have them magically gain access to relevant IAM roles as well as anything that group entails on other services. Obviously, removal from that group would revoke their access to the credentials in question. It wouldn't be the end of the world if my workflow involved modifying the directory server and separately creating and permissioning IAM users, but it doesn't feel ideal either. Perhaps in environments with a less pervasive directory infrastructure, that's less compelling.

Ideally I would like to keep as little information in LDAP as I can

Out of curiosity, why did you store sshPublicKey there in the first place? Are you treating an LDAP directory as a stop-gap place to keep sshPublicKey information until Amazon fleshes out its IAM functionality a bit more?

As far as a path forward, I feel fairly confident that I could implement the LDAP-based group authorization scheme I described above without much effort. If I were to implement it, I'd do so in a reasonably generic manner (user objects have a generic way to determine what roles they have access to) that could support an IAM-based alternative. I could submit such a thing in a PR and see if you'd be interested in it, but if you'd rather steer me in a direction more closely aligned with where you want to take it, I'm open to alternatives too! Perhaps the "user information" component (usercache.go I guess) should be easily pluggable and I could put my LDAP group implementation in there 😄

Anyway, thanks again for the great project!

[gaylatea]

No worries about delays - life has a way of catching up to us. Sounds from the other issues like you've been busy! 😺

Are you treating an LDAP directory as a stop-gap place to keep sshPublicKey information until Amazon fleshes out its IAM functionality a bit more?

Sort of. There's nothing in IAM that really allows us to store the information that we need. Perhaps making a SimpleDB table (something I considered, and am still considering for future improvements) with the username -> ssh key mappings would be a good alternative usercache implementation. LDAP was really just used because it was already present in AdRoll's corporate environment, but key/value store will do the trick.

I've been hesitant to put more info into LDAP because I honestly just couldn't figure out how to make an implementation of it that didn't require an inordinate amount of setup and maintenance when new roles were created, etc. I think I see what you're trying to go for with the groups, though:

• User authenticates to Hologram server through hologram me. (I don't think we should use this for hologram use, as it has too much potential to create confusion and the point of that is to exactly emulate production server roles.)
• Hologram checks with LDAP to see what groups the user is in (need a timed cache here, I would assume, as you wouldn't want to read every time). These groups have an attribute with an IAM policy document inside.
• These policy documents are merged into a single document.
• (Optional, but highly worthwhile, I think: merge these permissions with any that the user's IAM account has, if present.)
• This document is used as an argument to AssumeRole to union their permissions with the developer role provided by Hologram.

I'll be very interested in seeing the PR for this.

If I were to implement it, I'd do so in a reasonably generic manner (user objects have a generic way to determine what roles they have access to) that could support an IAM-based alternative.

Making that part of the UserCache interface would be great, that way other backing stores could make their own determinations as to what they want to allow.

Anyway, thanks again for the great project!

❤️ Thank you for all the excellent suggestions and helping us make Hologram more useful for more developers!

[walterking]

What do you mean by policy documents? Why shouldn't it just be a list of roles a user is allowed to assume?

[gaylatea]

Agh, I didn't think about that when I was reading through. Yes, you would want a list of those. For some reason I thought he wanted more granular permissions from the hologram me level.

Still something worth looking into eventually, but not quite what's being called for here, it looks like.