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.
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?
Why? I'm genuinely curious. I've never used their product, but their Wikipedia page says they are a San Francisco based company with end-to-end encrypted messaging and video conference calls[1]. And their home page[2] says "Fully encrypted. Enterprise-ready. Private."
At first glance it seems like a reasonable choice. US based and end-to-end encrypted seems to be what the military wants in this case.
I want to put on end to the "you can't contact Google" comments that comes up every time Google Cloud makes the front page.
You can contact Google Cloud. They are very responsive. I'm currently at a small startup using GCP, and I've been at similarly sized startups with equivalent AWS spends. I have found it easier to have serious discussions with GCP, compared to AWS.
We have dedicated GCP contacts. We actually have a Slack channel we share with our dedicated GCP contacts, so we can easily ask questions. Two of my coworkers just got out of a meeting with Google PMs less than an hour ago. Another one will be meeting at a Google office tomorrow. I had a meeting with about a dozen Google engineers and PMs from their database team(s).
Yes, you have to pay for support. They have a couple different support options, depending on your needs. But you have to pay for support with AWS too.
The one bad thing about Google Cloud support is their Level 1 support. It is very easy to submit a support ticket, and they will respond quickly. But if you are highly technical, and know what you are doing, and can research yourself, Level 1 support it nearly useless. They do make it easy to to escalate, with a prominent Escalate button in the ticket. And you can always escalate through your direct contacts (Account Manager, Technical Account Manager, Customer Engineer). But it would be nice if Level 1 could be bypassed, or were more technical. I think they are trying to iterate on the process. They recently started offering to have a video call a lot of the time, which isn't my cup of tea, but I think it is a sign that they are trying to improve the Level 1 support.
If you are using Google Cloud as part of a business, you will be able to contact them. You will probably have an account manager that you can probably meet in person with. If you pay for support you will be able to submit support tickets, real humans will respond, and respond quickly.
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.