3 ms·

It's good to see an article talking about this. A lot of organizations could benefit from using more than one account to enforce security (IAM is hard!) and sep

It's good to see an article talking about this. A lot of organizations could benefit from using more than one account to enforce security (IAM is hard!) and separation of concerns. It doesn't really explain it but to do this, the root account has to be enrolled for AWS Organization[1]. This is what is being used to handle all the accounts and consolidate the billing. It also allows to create rules span all the accounts. Recently terraform gained support for the Organization API[2] so it's possible to control the account list in a declarative manner. The biggest issue is that now that there are a lot of accounts, the developers need a way to switch between them. Using the IAM assume-role mechanism is a good way to avoid needing a lot of AWS keys per developer. I don't know if I agree with using Okta as it adds another party that now has access to AWS. I don't see the difference between having a AWS secret or and Okta secret in the keychain security-wise. Okta might provide audit logging facilities but so does AWS. In either case you will need to generate a `~/.aws/config` per developer. There is also a Chrome plugin[3] that can read this file format and populate the AWS Console switch role. I don't know if the extension publisher is reputable yet as it gives a lot of access to the extension. [1]: https://aws.amazon.com/organizations/ https://aws.amazon.com/organizations/ [2]: https://github.com/terraform-providers/terraform-provider-aws/pull/903 https://github.com/terraform-providers/terraform-provider-aw... [3]: https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl https://chrome.google.com/webstore/detail/aws-extend-switch-...

toomuchtodo 9y ago
It should be noted that Orgs should be setup when new AWS accounts are created, as it can be tricky to perform once your have systems in production. I would even go so far as to say if you want to commit to Orgs, create a new AWS account hierarchy and move your applications and infrastructure into it. EDIT: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html https://docs.aws.amazon.com/organizations/latest/userguide/o... "Warning: We strongly recommend that you do not attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key services."
- zimbatm 9y ago
  Agreed. One strategy that I have been using quite successfully is to: * create a new AWS account * setup IAM and AWS Org * add 2nd factor on the root account, put the Gemalto in a safe Then add the "legacy" account to the org and slowly port all the resources to fresh new accounts.
brazzledazzle 9y ago
If you already have an internal directory/SSO (e.g. Active Directory) the advantage to using something like Okta (or another decent SAML app/provider) is the user experience. It makes SSO really simple (you could install the agent on a desktop), has simple directory sync and allows you to create network source rules (e.g. trusted networks) and integrates with several 2FA/MFA solutions out of the box. If you don’t already have an internal system like Active Directory it might not be worth the extra single point of failure/compromise. I can see Amazon displacing these services over time (they have a lot of the components already) but last time I looked they weren’t there yet. I don’t want it to seem like this is a sales pitch either. Okta has plenty of warts, odd decisions, glaringly obvious missing features and has done some bizarre 180s in terms of organizational direction. It was a long time ago but one bug I won’t forget that was shocking: a combination of special characters in a password resulted in a sync failure for a couple of accounts. That’s bad on its own because it raises all kinds of questions about how they’re handling and sanitizing strings. But the whopper was that the errors presented to admins had the passwords in clear text. You would assume masking would be a key thing in their code and logging systems and it made me question if they even had masking at all if a user password made it all the way to the dashboard.
mnutt 9y ago
My organization evaluated Okta and I also came away worried about introducing another third party that had access to all of our services, both from a security perspective and as another point of failure. In particular, in Okta's SWA apps they have a setting for those apps to use the same password as the user's Okta password. If there's a way they do this without storing all of their user passwords unhashed, I couldn't figure it out and the Okta reps weren't able to provide a clear answer. Edit: I _can_ think of one potential solution: Okta initially sets user's password to a random string, when you authenticate with Okta / change your Okta password, they use the unhashed version to make admin calls to update the apps' password and never persist it. But they didn't give any indication that this was the case.

toomuchtodo 9y ago

It should be noted that Orgs should be setup when new AWS accounts are created, as it can be tricky to perform once your have systems in production. I would even go so far as to say if you want to commit to Orgs, create a new AWS account hierarchy and move your applications and infrastructure into it. EDIT: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html https://docs.aws.amazon.com/organizations/latest/userguide/o... "Warning: We strongly recommend that you do not attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key services."

zimbatm 9y ago
Agreed. One strategy that I have been using quite successfully is to: * create a new AWS account * setup IAM and AWS Org * add 2nd factor on the root account, put the Gemalto in a safe Then add the "legacy" account to the org and slowly port all the resources to fresh new accounts.

brazzledazzle 9y ago

If you already have an internal directory/SSO (e.g. Active Directory) the advantage to using something like Okta (or another decent SAML app/provider) is the user experience. It makes SSO really simple (you could install the agent on a desktop), has simple directory sync and allows you to create network source rules (e.g. trusted networks) and integrates with several 2FA/MFA solutions out of the box. If you don’t already have an internal system like Active Directory it might not be worth the extra single point of failure/compromise. I can see Amazon displacing these services over time (they have a lot of the components already) but last time I looked they weren’t there yet. I don’t want it to seem like this is a sales pitch either. Okta has plenty of warts, odd decisions, glaringly obvious missing features and has done some bizarre 180s in terms of organizational direction. It was a long time ago but one bug I won’t forget that was shocking: a combination of special characters in a password resulted in a sync failure for a couple of accounts. That’s bad on its own because it raises all kinds of questions about how they’re handling and sanitizing strings. But the whopper was that the errors presented to admins had the passwords in clear text. You would assume masking would be a key thing in their code and logging systems and it made me question if they even had masking at all if a user password made it all the way to the dashboard.

mnutt 9y ago

My organization evaluated Okta and I also came away worried about introducing another third party that had access to all of our services, both from a security perspective and as another point of failure. In particular, in Okta's SWA apps they have a setting for those apps to use the same password as the user's Okta password. If there's a way they do this without storing all of their user passwords unhashed, I couldn't figure it out and the Okta reps weren't able to provide a clear answer. Edit: I _can_ think of one potential solution: Okta initially sets user's password to a random string, when you authenticate with Okta / change your Okta password, they use the unhashed version to make admin calls to update the apps' password and never persist it. But they didn't give any indication that this was the case.