Comment by antoncohen | Hacker News Reader

Comment by antoncohen | Hacker News Reader

I'd like more detail on the advantages of AWS AssumeRole, and what attacks it is designed to protect against. It must be more than CloudTrail logs, because normal API usage gets logged to CloudTrail.

One thing I'd like to highlight is that SOC2 is about having controls (of your choosing), and documenting and proving you are following those controls. I think it is important to pick controls you actually want to follow, and that those controls aren't so specific that you get fenced in to a bad process.

I've worked at a few companies that have gone through SOC2, one of them (Dropbox) did it very well. I think the average engineer didn't need to know about SOC2, or what all the controls were, because the controls were well thought out, and automation took care of the proof. At another company every engineer was constantly saying "you have to do that because of SOC2", because the controls intruded on the way engineers worked.

"SOC2 requires that two people approve every PR". Hmm, no the accountants that created SOC2 don't know what PRs are. "Only members of the team called 'QA' are allowed to transition Jira tickets from state A to state B, SOC2 requires it". No, I'm pretty user SOC2 doesn't specify issue tracker workflows. "You need to name your git branched XYZ-abc-foo-bar, because of SOC2". You're telling me that accountants are specifying source control conventions?

The way it works best is when you have multiple accounts ,you have a single Identity account, which is where your user accounts live. This account basically allows sign in and assume role - oh and you can't assume unless you have authenticated with MFA.

Then, all your other accounts - dev, prod, service, whatever - simply have roles and no user management overhead - i.e you aren't duplicating users in a bunch of accounts and having to deal with a bunch of different identities.

SSO is based on AssumeRole which issues temporary credentials (session tokens) instead of using static credentials. SSO-like centralized access management is important to prove that when someone leaves your company that you cut off their access to all data and systems, much easier to do that when everyone uses SSO.

SOC2 doesn’t specify git branch logistics. In general you need to prove all system changes were reviewed, justified, and approved by another person. The goal is no single person can deploy unsupervised production system changes, and the justification for changes were approved and documented. How you do that is all in the art of IT.

As mentioned, AssumeRole is a critical part of a multi-account strategy, which is considered an AWS best practice. In addition to that, it is an integral part of an SSO strategy. Ideally, instead of a pile of IAM users with separate credentials, user identities should be federated from your identity provider (like Auth0, Ping, AzureAD, whatever). There are a number of setups, but they all boil down to your users trading their corporate identity for temporary AWS credentials via something like an AssumeRoleWithSAML call. This is only slightly more complicated to set up than a good IAM user/group architecture, but has the benefit of not needing to deal with IAM users and multiple sets of identities for your users. You can also map particular roles back to something like AD groups to control who can assume what.

Thanks, that was a very clear explanation. I know AssumeRole is needed for SSO, and I understand the benefits of SSO. The way the article phrased it it sounded like AssumeRole has some very specific benefit by itself.

And if the answer is "short lived credential", then I'd like to understand how short lived credentials that require a long lived credentials to get them are better than long lived credentials, if both can be just as easily revoked.

Reply on news.ycombinator.com