4 ms·
Thanks for posting this here. I'm the author of this blog post. Feel free to ask me any questions you might have.
by ejcx 9y ago
Thanks for posting this here. I'm the author of this blog post. Feel free to ask me any questions you might have.
- scrollaway 9y agoTangential: Why Okta over some other provider? GSuite can be used as an SAML provider, can't it?
- ejcx 9y agoI honestly don't know of the feature parity between the two, but we are definitely Okta power-users having added close to 500 apps in the last year. I don't know if we could drive all of the same processes we have built (especially on the HR side) using GSuite.
- marcc 9y agoGSuite can be an IdP for SAML but it’s sometimes limited. AFAIK you can’t use it to connect to AWS using SAML because AWS makes some assumptions about attributes in the identity. I may be wrong here, but I tried to do this a few months ago (with Duo and Yubikeys added in) and was not able to get it working. I ended up using Okta and it was simple.
- debaserab2 9y agoYou can do it. It feels a little hacky - you have to execute a few actions via gsuites API instead of via a UI. https://aws.amazon.com/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-apps/ https://aws.amazon.com/blogs/security/how-to-set-up-federate...
- wgjordan 9y agoAbout a year ago, I migrated my team's AWS access from manually-provisioned AWS keys to GSuite authentication, using a combination of SAML and OpenID Connect (OIDC): - Detailed instructions for Google-federated login to the AWS Management Console through SAML are available [1], and worked more or less as described. - CLI/API access is a bit trickier and less thoroughly documented, but is possible using the 'Web Identity Federation' feature [2]. Basically, you generate/refresh temporary AWS credentials by passing a Google OIDC token to the AssumeRoleWithWebIdentity API. The tricky part is keeping both your Google OIDC and AWS STS tokens conveniently refreshed. I wrote some open-source glue code for this that hooks into the AWS Ruby SDK and CLI [3]. It's still a little rough around the edges and not yet extracted into a standalone project, but it's been working well enough for my team over the last year. [1] https://aws.amazon.com/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-apps/ https://aws.amazon.com/blogs/security/how-to-set-up-federate... [2] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr... [3] https://github.com/code-dot-org/code-dot-org/blob/staging/lib/cdo/aws/google_credentials.rb https://github.com/code-dot-org/code-dot-org/blob/staging/li...
- mnutt 9y agoDo you have some sort of failsafe in place for developers to be able to access AWS in the event of an Okta outage? Or are the Okta user sessions long-lived enough that you'd be able to mitigate some other way if Okta was down?
- ejcx 9y agoIf Okta is down our infrastructure should continue to function and scale up and down as needed. If there was an emergency we have our root accounts to recover access, but it's a good point that we should probably have a second IDP as a backup.
- lox 9y agoGlad Segment is making good use of aws-vault and it's components! Did you consider whether adding okta support in aws-vault might have made sense? I've been thinking about doing that for a while, interested what made y'all decide to create a new one. P.S. Any chance of a link back in the mention of aws-vault in the article? (aws-vault author here)
- ejcx 9y agoHey. I'll make sure to update the blog to include a shout-out to aws-vault! We were heavy users for the last few years. We are sometimes wary about contributing stuff like this upstream because it's not always accepted, and then we are in a weird spot maintaining a fork (it happened with the bitly oauth proxy when we added okta support). I'll see what type of work it would take to make it fit in to aws-vault nicely!
- exidy 9y agoHi there. I'm confused by your statement that "The integration guide recommends connecting the identity provider to each AWS account ..." This used to be the way Okta recommended integrating to AWS, but in the guide you linked[1] they are using pretty much exactly the same approach you did - authentication to an identity account (ops account in your terminology) then assume-role into the target account. I can't see any major differences between the standard Okta approach and the way you outlined in your blog. Could let me know if I missed something? [1] https://support.okta.com/help/servlet/fileField?retURL=/help/articles/Knowledge_Article/Amazon-Web-Services-and-Okta-Integration-Guide&entityId=ka0F0000000MeyyIAC&field=File_Attachment__Body__s https://support.okta.com/help/servlet/fileField?retURL=/help...