|
Yeah AWS SSO is quite cool and good these days. Really my only gripe (and this applies to regular old IAM too) is that you still can’t be logged into more than one console at once. So if I want to look at things in more than one account simultaneously I have to open incognito windows or multiple browsers or some poo poo. Which is very awkward. I don’t know how they would reasonably make that work, though.
|
#
?
Nov 28, 2022 22:13
|
|
|
|
| # ? May 17, 2024 18:37 |
|
|
thanks for all the help. seems like it's readily doable, just have to make, what are effectively, policy groups.
|
|
#
?
Nov 28, 2022 22:22
|
|
|
Docjowles posted:Yeah AWS SSO is quite cool and good these days. Really my only gripe (and this applies to regular old IAM too) is that you still can’t be logged into more than one console at once. So if I want to look at things in more than one account simultaneously I have to open incognito windows or multiple browsers or some poo poo. Which is very awkward. I don’t know how they would reasonably make that work, though. I die a little bit every time I'm logged into the prod aws account and then realize I need to do the whole login MFA dance again for the dev account in incognito.
|
|
#
?
Nov 28, 2022 22:25
|
|
|
IMHO It's much better UX to just use regular IAM roles: - Create everyone an IAM user (trivial) and configure the user with an MFA device (<10 min per user, async slack message) - Give them a policy that allows sts:AssumeRole on an arbitrarily complex mapping of AccountName + RoleName - Add a condition that only allows sts:AssumeRole to succeed with a valid MFA code That's it. If they want to use the CLI, assume a role. If they want to use the web UI, log in like normal -> assume a role. If you want to swap accounts in the web UI, hit the "Switch Role" drop down in the interface, which has a handy "recent roles" feature. If you want to swap accounts in the CLI, use a role profile, or juggle some vars. From a management perspective this lets you implement "The product management role has RestartInstances permissions in the UAT accounts" by, very simply, adding a policy element that grants this action, to the product management role, in the UAT accounts. To do this in AWS SSO you would need to either create a new permission set -> which results in a new option for the user to select, called like "ProductRoleUATAccount", that has different permissions from ProductRoleProductionAccount, or you would need to overload the policy to check for aws:PrincipalAccount -> ForAnyValue -> StringEquals -> each, UAT, account, ID. If you do ForAnyValue + StringEquals you also have to explain to your auditor why your in-scope permissions policies have "Allow Product" statement in them, but it's totally safe because of this nested JSON, and we ensure that changes to the nested JSON are safe because of [...]. It's bad.
|
|
#
?
Nov 28, 2022 22:31
|
|
|
12 rats tied together posted:IMHO It's much better UX to just use regular IAM roles: This means you gotta write your own sync of your IDP to IAM users though, which is a large ask. I don’t think the AWS SSO approach of having different roles for different accounts is all that bad, assuming in your example UAT account and Production Account are different AWS accounts. I can definitely see that breaking down at scale if you’ve hundreds or thousands of AWS accounts, but for most orgs with a double digit or smaller amount of AWS accounts, using AWS SSO is easy if you use one permission set/role per AWS account. I don’t really believe in multiple roles per user group per AWS Account because if you can sign into role A you can sign into role B, so I question whether or not you gain much meaningful security. “Click the role that corresponds to the AWS account” is not, I feel, a big ask from a UX perspective. E: AWS def hosed up by tying identity so closely to an AWS account imo. GCP’s projects and Azure’s Resource Groups are much much cleaner implementations of namespacing from a user perspective. The Iron Rose fucked around with this message at 23:02 on Nov 28, 2022 |
|
#
?
Nov 28, 2022 22:55
|
|
Cat Army 
|
Methanar posted:I die a little bit every time I'm logged into the prod aws account and then realize I need to do the whole login MFA dance again for the dev account in incognito. I have multiple chrome profiles, one for each AWS account I have to work on. Slightly painful, but it keeps me sane and means I only have to login once per day for each account I'm working on that day. This also means account access via our landing zone, which remembers that my laptop is a trusted device, doesn't ask for MFA each time I log in.
|
|
#
?
Nov 28, 2022 22:56
|
|
|
Multiple roles per user is for when you have access to perform multiple types of job duty, which are meaningfully segregated (e.g. political firewall, merger nonsense, SOX controls, things of this nature). It's good that Product can't CloudFront:CreateInvalidation, even if some members of product are also developers and have this permission through a side channel. Decoupling the definition of a job duty from its performers is good because the lack of coupling reduces the scope. Kevin might be on a new team that has a hybrid PO/Developer team lead. Compliance shouldn't have to ingest this new organizational skeleton and produce new scaffolding for ensuring Kevin's actions are compliant, because Developer and PO already exist and already are compliant. It's way easier to "prove it" when a thing is what it actually is, and proving it is really all that matters. You can do this in AWS SSO, of course, but the UX on the administration and the user side is significantly worse, because of the aforementioned many-many-many relationship required by the principals -> permission sets -> accounts model.
|
|
#
?
Nov 28, 2022 23:14
|
|
|
ledge posted:I have multiple chrome profiles, one for each AWS account I have to work on. Slightly painful, but it keeps me sane and means I only have to login once per day for each account I'm working on that day. What is it like having an IT group that can correctly configure MFA to not reauthenticate you 69,000 times per day? I feel like I spend half my life responding to Duo prompts
|
|
#
?
Nov 29, 2022 08:48
|
|
|
Docjowles posted:What is it like having an IT group that can correctly configure MFA to not reauthenticate you 69,000 times per day? I feel like I spend half my life responding to Duo prompts I work for a small consulting company, so I am my companies IT group  I do not miss corporate IT one bit (nor HR, or middle managers, or any of that bullshit, I thoroughly recommend it).
|
|
#
?
Nov 29, 2022 09:51
|
|
|
12 rats tied together posted:IMHO It's much better UX to just use regular IAM roles: lol, lmao. Even with 50 engineers this is not trivial when you start running into security policies saying "IAM Credentials must be rotated every 90 days". Plus this means there's another thing to provision while onboarding, or deprovision when offboarding. Moving to using Okta as our source of truth (transitive, it feeds from HRIS) and using saml2aws first and now AWS SSO, has made this a lot simpler to manage. quote:To do this in AWS SSO you would need to either create a new permission set -> which results in a new option for the user to select, called like "ProductRoleUATAccount", that has different permissions from ProductRoleProductionAccount, Yep, this is what we do. We create a set of permissions ("readonly", "billing", "security audit", "power user") et c and assign these to Okta groups ("aws-<account>-billing"). If you need access to more than the readonly role or a different account, you request it from IT and they add you to the group for it and you set it up in SSO.
|
|
#
?
Nov 29, 2022 11:59
|
|
|
“Don’t use IAM users” - everyone who works for AWS (for what that is worth)
|
|
#
?
Nov 29, 2022 12:53
|
|
|
Yes, seriously. IAM users bad, being able to assume roles via OIDC good.
|
|
#
?
Nov 29, 2022 13:19
|
|
|
luminalflux posted:lol, lmao. Even with 50 engineers this is not trivial when you start running into security policies saying "IAM Credentials must be rotated every 90 days". I would offer your security team the advice that technically the user doesn't have access to anything, in the proposed model, only the role does. Arzakon posted:“Don’t use IAM users” - everyone who works for AWS (for what that is worth) It's our job, not AWS', to consider our own specific security and management needs and create a set of platform objects that solves for them in the cheapest, easiest, etc., way.
|
|
#
?
Nov 29, 2022 17:21
|
|
|
That guideline exists in a lot of cloud security posture things - AWS Security Hub, Bridgecrew et c. You also still have to manage credentials when onboarding/offboarding engineers, which isn't an issue if you use SSO. IAM Identity Center (fka SSO) is a lot smoother experience as a whole, even if it has some warts.
|
|
#
?
Nov 29, 2022 17:35
|
|
|
I don't agree with the specific conclusion that management through Identity Center is smoother as a whole, but I think we're on the same page + it's really sad that this is even up for debate. "Use the thing that is fundamentally better" should be the easiest slam dunk of all time, but here we are. IMO, my accounts are databases, so I don't want to SSO map into them in the same way that I wouldn't want SSO map into mysql. The graphs are in grafana, the deployments are in the deploy tool, the logs are shipped to sumo, etc. The types of access that should be given out in this model are like "Edge team needs to manage EdgeApp which uses CloudFront" so the foremost concern is that there is a single entity that needs different permissions in every account, which SSO totally drops the ball on compared to the other solution which has been around for over a decade.
|
|
#
?
Nov 29, 2022 18:00
|
|
|
Where your solution breaks down is automatic user provisioning/deprovisioning - something that security requires and is top of every vendor review - along with smoothness of use for engineers. I'm not following how SSO can't provide "Edge team needs to manage EdgeApp which uses CloudFront" - we just assign that PermissionSet to the `aws-<account>-edgeapp` group and engineers who would need access to it are added to that Okta group and automatically get access.
|
|
#
?
Nov 29, 2022 18:22
|
|
|
Doesn't help the "compare things simultaneously" aspect but I've found the https://github.com/tilfinltd/aws-extend-switch-roles extension to be very handy for bouncing between accounts
|
|
#
?
Nov 29, 2022 18:40
|
|
|
I've never been part of a compliance satisfaction scheme that has required me to describe the exact mechanism by which users are provisioned and deprovisioned, typically the requirements I see are that the processes must be documented, the documented process must be followed, and the deprovisioning must be able to materialize an access revocation within some extremely generous timeframe. The actual mechanism for it is trivial, IAM has an API or you can even click in the web interface if you don't like it. Plenty of compliant and publicly traded technical organizations run on checklists and email. My personal preference is gitops iac, but it doesn't really matter. The users that exist and their authorizations are fully described by the main branch of a git repository at all times, changes to these definitions are peer reviewed and each link to a concrete instance of a business process (JIRA ticket) which also links to other events from the HRIS. Then you just need to prove that: No changes to the git repository were made without peer review. No changes to the users were made except by the git repository's approved mechanisms. No changes were made that were not linked to a JIRA ticket, and every JIRA ticket for this process always linked to your HR bullshit. You sill get to check "yes" on whatever stupid questionnaire you received from the bored secops team in the fortune 500. If they have any further questions you can just give them your SOC 3 report.
|
|
#
?
Nov 29, 2022 18:45
|
|
|
12 rats tied together posted:AWS' job is to have an answer for every question so you can bring your spend to their platform, and they're very good at it. True, I do want you calling me to ask questions about interesting things that might make money for AWS and not the lambda script you invented to mimic SSO but for IAM users. Also I don’t like getting the “is it our fault or did customer do something dumb” e-mail when they have a very public security breach.
|
|
#
?
Nov 29, 2022 19:03
|
|
|
Arzakon posted:and not the lambda script you invented to mimic SSO but for IAM users. Just to clarify, this would be a thing that rotates IAM keys, not a thing that mimics SSO. I'd also probably just use yours https://github.com/aws-samples/aws-iam-access-key-auto-rotation instead of inventing it again.
|
|
#
?
Nov 29, 2022 19:09
|
|
|
Can AWS employees still use Slack or is everybody being forced to use "Wickr" now?
|
|
#
?
Nov 29, 2022 20:34
|
|
|
We don't use Workmail internally either  Workdocs over *Box is painful enough.
|
|
#
?
Nov 29, 2022 21:53
|
|
|
12 rats tied together posted:Just to clarify, this would be a thing that rotates IAM keys, not a thing that mimics SSO. Ah okay I thought we were talking about building something to sync corporate user directory to IAM users in a way that would pass any compliance standard that isn’t “my auditor doesn’t understand or know what AWS with is so it doesn’t matter”.
|
|
#
?
Nov 30, 2022 20:02
|
|
|
In case anyone else is dumb like me, I just came across this and it is very helpful, especially since it can include SCPs that I always forget about : https://policysim.aws.amazon.com
|
|
#
?
Dec 1, 2022 19:44
|
|
|
Are there any situations where a reserved instance will also reserve capacity or is that entirely done by capacity reservations?
|
|
#
?
Dec 2, 2022 22:05
|
|
|
LtDan posted:Are there any situations where a reserved instance will also reserve capacity or is that entirely done by capacity reservations? I believe if you buy an RI for a specific AZ within a region it reserves capacity. If you buy a more generic one for the region, it does not. https://aws.amazon.com/premiumsupport/knowledge-center/ri-reserved-capacity/
|
|
#
?
Dec 2, 2022 22:16
|
|
|
Good to know, thanks!
|
|
#
?
Dec 2, 2022 22:49
|
|
|
Thanks Ants posted:Can AWS employees still use Slack or is everybody being forced to use "Wickr" now? Still Slack unless that changed in the last week or so. You can't shift an org the size of AWS over to new tooling for stuff like collaboration quickly.
|
|
#
?
Dec 3, 2022 22:14
|
|
|
Was going to post some gossip about that from my time there but my NDA is apparently *three* years post severance. Anyway without getting into specifics covered by the NDA. Slacks internal roll out at Amazon was an unmitigated disaster and I'd be impressed if they ever got it running half way as well as some of the free instances I'm on right now. Largely because they had far far too few people running it for what is likely one of the largest slack servers in the world. So the idea of them moving to another collaboration platform is laughable at best.
|
|
#
?
Dec 4, 2022 04:52
|
|
|
This is interesting. I have not seen any issues with Slack since it was deployed and thank goodness for that. Chime sucks. My experience with the Slack rollout was, “here, you are using Slack now.” “Okay.” What was the disaster to which you are referring?
|
|
#
?
Dec 16, 2022 22:08
|
|
|
Agrikk posted:This is interesting. Bots required manual approval via a team that had like 5 people and there was no process in place for that or many other things. There was no way to join private channels without being added by hand. FC/contract employees were unable to use slack. Emojis gave people with epilepsy seizures at least twice due to bad internal actors. Amazon tried to make retention two weeks likely to cover something up only to brown out slack globally when they rolled it back after hiding whatever they sought out to hide. Plenty more but those are what I can think of offhand.
|
|
#
?
Dec 17, 2022 00:30
|
|
|
jiffypop45 posted:Bots required manual approval via a team that had like 5 people and there was no process in place for that or many other things. There was no way to join private channels without being added by hand. FC/contract employees were unable to use slack. Emojis gave people with epilepsy seizures at least twice due to bad internal actors. Amazon tried to make retention two weeks likely to cover something up only to brown out slack globally when they rolled it back after hiding whatever they sought out to hide. 
|
|
#
?
Dec 17, 2022 00:31
|
|
|
|
|
#
?
Dec 17, 2022 00:36
|
|
|
jiffypop45 posted:Bots required manual approval via a team that had like 5 people and there was no process in place for that or many other things. There was no way to join private channels without being added by hand. FC/contract employees were unable to use slack. Emojis gave people with epilepsy seizures at least twice due to bad internal actors. Amazon tried to make retention two weeks likely to cover something up only to brown out slack globally when they rolled it back after hiding whatever they sought out to hide. :party_parrot:
|
|
#
?
Dec 17, 2022 01:42
|
|
|
Yeah it's still a bit of a pain in the rear end (Does this channel exist and private, or does it not exist at all? WHO KNOWS) but I think I'm not much of a Slack poweruser. I'm sure the team running it is overloaded though. Still way better than Teams.
|
|
#
?
Dec 17, 2022 21:50
|
|
|
Falcon2001 posted:Yeah it's still a bit of a pain in the rear end (Does this channel exist and private, or does it not exist at all? WHO KNOWS) but I think I'm not much of a Slack poweruser. I'm sure the team running it is overloaded though. That’s kind of the point of a private channel
|
|
#
?
Dec 18, 2022 01:03
|
|
|
Blinkz0rz posted:That’s kind of the point of a private channel I'm on a slack server with a tool that allows you to list the private channels in a directory that have a specific bot in them so other people can find them. Private channels are used by ERG's as safe spaces for venting/getting resources and sometimes it can be difficult to get into them to have access to that sort of resource especially if you're not sure about whether they exist or not. This was a big issue since in terms of intersectionality, shot up plane images aside, people who are in marginalized communities often are working fc and contract jobs. So their inability to both join, and find places for collaboration with peers was a really massive frustration from a DEI perspective. And like any good FAANG company Amazon loves to :circlejerk: about how amazing it is at DEI despite being middling at best.
|
|
#
?
Dec 18, 2022 16:12
|
|
|
loling that people are on a big company-run Slack and complaining that they can't create actually private channels. My company essentially says Keybase should be used for private comms as a best practice rather than to use Slack if it's that important. We're open by default but also expect people to be sensible and not shitpost hard on the drat company Slack. Company lets people link to outside Discords and Slacks that are even ex-employee run and let people be idiots there if anything. Not saying we're some benchmark standard to go with but this doesn't seem like rocket science to me.
|
|
#
?
Dec 18, 2022 17:23
|
|
|
necrobobsledder posted:loling that people are on a big company-run Slack and complaining that they can't create actually private channels. My company essentially says Keybase should be used for private comms as a best practice rather than to use Slack if it's that important. We're open by default but also expect people to be sensible and not shitpost hard on the drat company Slack. Company lets people link to outside Discords and Slacks that are even ex-employee run and let people be idiots there if anything. Not saying we're some benchmark standard to go with but this doesn't seem like rocket science to me. Yeah to be clear my complaint isn;'t 'oh no my slack channel isn't actually private' more like 'people create private slack channels and then expect people to be able to find them', because Private breaks both discoverability and access, and in my experience most people actually care about the access restriction and don't really give a poo poo / actively dislike the behavior of the discoverability changes.
|
|
#
?
Dec 19, 2022 04:12
|
|
|
|
| # ? May 17, 2024 18:37 |
|
|
Falcon2001 posted:Yeah to be clear my complaint isn;'t 'oh no my slack channel isn't actually private' more like 'people create private slack channels and then expect people to be able to find them', because Private breaks both discoverability and access, and in my experience most people actually care about the access restriction and don't really give a poo poo / actively dislike the behavior of the discoverability changes. The intent is kind of in the name, isn't it? Sounds a lot like PEBCAK imo.
|
|
#
?
Dec 19, 2022 15:18
|
|