1

We have AWS accounts for dev, staging, and prod. We use AWS SSO via Okta, and define groups like "Developers" and "Support" in Okta.

Developer group should have broad access to our AWS dev account, but limited access in staging and prod. Support group should have AWS access as well, but also different permissions by account.

How can I allow group members to log in, then have suitable permissions depending on which account they access?


Details:

AWS SSO Permission Sets are linked to the AWS Start Page. This lists accounts a user has any access to, and displays one or more permission sets they can use. Permission Sets seem to be oriented around granting users the ability to log into several accounts with the same access -- admins might all have AWSAdministratorAccess and others might have ReadOnlyAccess, for example.

My use-case is different, though: I want to create different accesses depending on which account a given user logs into.

I think it's possible to do this with permission sets - e.g. developer-dev, developer-staging, developer-prod. But it seems messy to me. Also in reality we'll have a number of groups (developers team A, B, C) all of whom need different access, so there's kind of an explosion of permission sets and accounts.

I would like a developer to log in as "Developer" and depending on which account they log into gain the right permissions. I can do most of this using standard IAM Roles. The "developer" role in production might be ReadOnlyAccess, where in Staging it might have some additional permissions, and in dev might have PowerUserAccess. We manage these sorts of things using Terraform already.

I like the SSO multi-account login page. I also like the being able to switch roles (and accounts) from the AWS Console. Is there a simple approach I am misunderstanding that will let me do both?

2
  • I'm in the same boat as you, now that you've been doing this for two months, would you mind answering your own question or shedding some light on your findings?
    – ray sn0w
    Dec 8, 2021 at 19:38
  • The trick for us is that Okta/SSO maps to permission sets map to IAM roles which in turn map to RBAC in k8s. But each of our 100+ services have RBAC roles limiting access. So unless we propagate each service up through the chain (a mess) we need broader perms at the top level (Okta) and narrower at the bottom. We still haven't quite sorted that out. Will let you know if we do! Dec 12, 2021 at 16:55

0

You must log in to answer this question.

Browse other questions tagged .