Please don't do what this article advises. These are 10 min of my life I will never get back...
IAM is not that complicated. The example diagram for AWS is showing all the features available. You can use only what you require.
Do two things from the beginning:
1) Least Privilege - Only the permissions required: You need to do that, because due to the constant zero days around the different software vendors, you are statistically guaranteed to have a security event. Establishing security boundaries will allow to contain the damage.
In combination with....
2) Temporary Privileges - Assume the roles with the permissions you require only when you required them: This will make it harder on an attacker, since they will need to compromise you while you are holding those elevated privileges. When you finish your task, either manually or programmatically, detach from the role or assume a different one with lower or different permissions.
The article completely addresses the problems in #1 and you’ve offered no solutions. It offers a solution for determining what the hell the least priveleges are, while you assume prescient knowledge of them without justification. Your #2 is also exactly one of its recommendations.
> The article completely addresses the problems in #1 and you’ve offered no solutions.
You don't define the privileges you need, by running around with full privileges. The article is pitching some kind of tool the author developed, but you can do the same at least for AWS, for a long time. And if you don't know what policies you need you should talk to either the vendor or the application creator, as you will never be able to exercise all the compute paths...
I really love the trend of simply restating what an article argues against without addressing the actual article's points.
I had an exhausting discussion on Reddit about why storing UTC is not always sufficient from commenters who continually proved they hadn't read the article or the rest of the the comments.
I'm gonna go with "a hyperbolic, but potentially-necessary corrective to the mass cargo-culting of dev practices only appropriate to global-scale organizations, with a possibly egotistical amount of clickbait self-promotion" on that one.
Temporary Privileges is an example of security theater. It does not change the attack surface in a threat model because the model is not temporal. Has anyone ever shown a practical evidence that the attacker will face a problem waiting for the elevated permissions to support this idea?
And if you still really want to do that, you don't need AWS roles as a separate concept for this. You can just use temporary membership in groups.
AWS IAM model is overcomplicated compared to GCP/Azure.
It becomes clear when you try to migrate the project with multiple envs (projects in GCP aka accounts in AWS) with cross-env accesses.
It's not just theater, it can be the difference between someone finding an unlocked laptop that needs to refresh their access before doing more actions or just having 100% unfettered access. This is only one attack vector that gets safer by temporary tokens with short expiries, and for the dev under normal work conditions just means every few hours (or whatever TTL) you need to place your finger on your fingerprint reader for 1 second.
I think you’re talking about something different. AWS session tokens let you use your SSO to request session tokens that have a short expiry. So you can do API/console actions but if an attacker takes the creds, they expire. It also lets you generate session tokens that only have the subset of your allowed perms that you need for that workflow.
Yea. Like, I’m 100% on board with the idea that AWS IAM is full of footguns, is overcomplicated, and is hard to get right (I assume other cloud platforms are similar, but my expertise is largely specific to AWS).
But also it’s a complex and very important problem space.
> Temporary Privileges is an example of a security theater. It does not change the attack surface in a threat model because it's not temporal. Has anyone ever shown a practical evidence to support this idea?
I agree. I think the benefit of this is quite low. If someone takes over your machine, things are lost anyways. If they take over your machine but for some reason cannot access your password manager (or so) or your 2fa to increase priviledges, you at least gain some time before the attack happens since the attacker has to wait - but it's not a major win.
The only case where this really helps is if the attacker gains only temporary access to you (maybe a temporary vulnerability in the browser) but can't "persist" it. In that case, you can reduce the blast radius.
Are you aware that you can associate an EC2 instance profile on a temporary basis with a role? And attach and detach them via api or on a schedule? Because if you do that, and you hack the machine (Linux, Windows or Mac not relevant...), but you don't have the role with the privileges you need, you are going nowhere.
Yeah, so that means the attacker has to wait for the next schedule. As I said, that's an advantage but I wouldn't classify it as a major win.
It's different if you use a different machine for the priviledged account. Then an attacker has to take over that second machine too. IMHO this is a mucher better concept, but also increases friction significantly.
It also helps in large companies where lots of people may have needed the higher permissions over the years - if you do temporary permissions then someone currently/soon having those permissions needs to be hacked, as opposed to hacking any one of the many people who needed those permissions a few years ago and still have them because they weren't temporary and got forgotten about.
I think this is a different case though. The point of those "temporary priviledges" is not so that someone only can use them sometimes, it's that they only do use them sometimes.
What you say (that people should only have the permissions that they need) is orthogonal to that.
Why do you assert that all threat models have no temporal component?
A realistic attack that compromises a low privilege session may not be able to leverage that into higher privileges. Therefore, limiting the use of high privilege to a smaller window of time definitely reduces the attack surface.
GCP handles #1 with their recommended actions on IAM roles. Good luck doing this manually. GCP will give adivce on each IAM role, which person hasn't used their access in 3 months and encourage you to take action (remove it).
GCP has a glaring problem with temporary privileges. The console doesn’t support them. So if there is some operational activity that a user needs to do via gui rarely you either have to manually give and take those permissions or let them sit with elevated permissions all the time.
And the lack of roles of roles is beyond idiotic, it’s downright dangerous.
Just temporary add the user to yet another group with the needed permissions. Or use the IAM conditional policy.
Or impersonate a service-account (which is more or less the same as asuming AWS role)
GCP's lack of "AWS role" concept is great and straigtforward.
As well as its lack of both identity-bound policies and resource-bound policies at the same time.
IAM is not that complicated. The example diagram for AWS is showing all the features available. You can use only what you require.
Do two things from the beginning:
1) Least Privilege - Only the permissions required: You need to do that, because due to the constant zero days around the different software vendors, you are statistically guaranteed to have a security event. Establishing security boundaries will allow to contain the damage.
In combination with....
2) Temporary Privileges - Assume the roles with the permissions you require only when you required them: This will make it harder on an attacker, since they will need to compromise you while you are holding those elevated privileges. When you finish your task, either manually or programmatically, detach from the role or assume a different one with lower or different permissions.