Hacker News Reader

Comment by ejcx | Hacker News Reader

Thanks for posting this here. I'm the author of this blog post. Feel free to ask me any questions you might have.

Do 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?

If 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.

Glad 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)

Hey. 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!

Hi 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...

Tangential: Why Okta over some other provider? GSuite can be used as an SAML provider, can't it?

I 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.

GSuite 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.

About 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-federate...

[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

[3] https://github.com/code-dot-org/code-dot-org/blob/staging/li...

You 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-federate...

Reply on news.ycombinator.com