Skip to content
This repository has been archived by the owner on May 18, 2021. It is now read-only.

ATTENTION: aws-okta is on indefinite hiatus #278

Closed
nickatsegment opened this issue Jan 20, 2020 · 36 comments
Closed

ATTENTION: aws-okta is on indefinite hiatus #278

nickatsegment opened this issue Jan 20, 2020 · 36 comments
Labels

Comments

@nickatsegment
Copy link
Contributor

nickatsegment commented Jan 20, 2020

Hi all. Unfortunately Segment (and specifically I) will no longer be maintaining aws-okta, for the foreseeable future.

I tried to revive aws-okta with v2, but unfortunately it's just proven to be too much of a time sink to justify.

Several other OSS projects exist that can do what aws-okta does. saml2aws stands out in particular, with a nicer TUI, more providers, lots of MFA options, etc. I haven't done a security audit or anything, but at first blush it looks pretty competent and well-organized. It stores your session creds on disk instead of in a keyring, but I believe chaining this with aws-vault somehow would give you roughly the same level of protection.

I might also recommend forking aws-okta, perhaps starting from my 2.0.0-rc1 branch. I couldn't detangle some of the lesser used features.

I'm going to leave Issues and PRs open for a while, but only for critical, straight-forward bug fixes. No new features will be developed or added.

v1.0.0 is the final major release.

@marshallbrekka
Copy link
Contributor

Shameless plug:

Since I know some of the motivation for 2.x was to provide a pkg interface as well as a CLI, figured I would call out the project okta-auth. It provides an interface for driving the user authentication portion of the flow, resulting in an Okta session token.

It doesn't cover 100% of the functionality of aws-okta (notably obtaining AWS credentials from the Okta session), but can be used as a building block towards that goal.

It's used internally at Fair to power our CLI for obtaining AWS credentials, as well as some internal application credentials not associated with AWS.

@nickatsegment
Copy link
Contributor Author

That's awesome; plugs encouraged! Part of the reason I had to give up was the feeling that with some work we could reuse parts of other FOSS instead of writing our own. But then aws-okta would just be a wrapper around the pkgs of saml2aws or something similar.

Personally it feels to me like everybody should probably just build their own in-house aws-okta-like. Making a tool to serve every use case is way too hard.

@jspiro
Copy link

jspiro commented Jan 22, 2020

Who owns the brew package? Is there a chance segment will ever continue this, or will someone at segment be able to promote brew to a new maintainer when a fork ultimately takes over?

Alternately, perhaps there should be an aws-okta/aws-okta account on GitHub, and you can bless some of your favorite maintainers to take over the project.

@j0nathontayl0r
Copy link

Thank you for the work that you've already done here @nickatsegment, I can understand how much time it'd be to support and maintain this tool.

Yours is one of the better polished services and I've been using it for a little while now.

/salute

@nickatsegment
Copy link
Contributor Author

Who owns the brew package?

The brew package is maintained by non-Segmenters. So they could choose to use a new fork.

Alternately, perhaps there should be an aws-okta/aws-okta account on GitHub

Yep, that's an idea. Someone can make an org. But I wouldn't trust that fork any more than e.g. github.com/rando_calrissian/aws-okta unless it had some elaborate foundation behind it or something.

@wolfeidau
Copy link

Thanks for the mention @nickatsegment I have added the super handy console login option to Versent/saml2aws#410

There are some great ideas in aws-okta which I am hoping to adapt to saml2aws especially some of the caching and security features.

Cheers.

@queue-tip
Copy link

Hi all. Unfortunately Segment (and specifically I) will no longer be maintaining aws-okta, for the foreseeable future.

I tried to revive aws-okta with v2, but unfortunately it's just proven to be too much of a time sink to justify.

Several other OSS projects exist that can do what aws-okta does. https://github.com/Versent/saml2aws stands out in particular, ...

I don't think that link works. It takes you to issues for aws-okta.

The link should be https://github.com/Versent/saml2aws

@nickatsegment
Copy link
Contributor Author

Fixed! I know markdown, I swear.

@jeffwecan
Copy link

Would y'all be amenable to transferring this repository to folks interested in maintaining the project moving forward?

(If not, it would be cool if any folks who plan on forking the repo and continuing to work in it share their intentions here 😉.)

@nickatsegment
Copy link
Contributor Author

nickatsegment commented Feb 4, 2020

@jeffwecan I personally am into transferring ownership. I'll have to look into if there are any company policies around this (namely Legal).

Also, I'm pretty sure any random can make an aws-okta/aws-okta org and repo and copy the history there. I.e., technically, I'm not sure you need my sign-off.

@nickatsegment
Copy link
Contributor Author

Actually, I think unless there's a serious effort to share maintenance (it's not just one person/company), you may as well just put it under your personal/company org. aws-okta/aws-okta makes it seem like there's some sort of foundation behind it.

@jeffwecan
Copy link

I'll of course grant that, as far as git history is concerned, the distinction of original repository versus fork isn't that important. I just imagine the historical GitHub metadata would be more readily accessible for users with the continuity a transfer would enable.

On your last comment, I agree that a generic organization is generally the best route for a widely used project if it's no longer to be tied to a specific individual or business (and is the route I took when leaning in on https://github.com/hvac/hvac). An "unattached" organization seems to make it far easier to potentially recruit additional maintainers down the line ☺.

In any case, thanks for scoping it out!

@nickatsegment
Copy link
Contributor Author

Yeah, I suppose if we just did a copy instead of transfer, we'd lose all the tickets.

@eldondevat
Copy link

It looks like somebody already did this: https://github.com/aws-okta/ . Does anyone know who? There are no public organization members.
I am a fan of aws-okta, is there any reason (upcoming api deprecation, etc) that it needs a major revamp? Sometimes software continues to be useful without frequent revision outside of bugfixes. I have considered some minor improvements (and have some locally). It has been so effective for us, that I would hate to direct people away from it like in c6464ae

@mtibben
Copy link

mtibben commented Feb 20, 2020

Is it worth considering rolling SAML capabilities into aws-vault? There are a couple of open issues in aws-vault suggesting exactly that 99designs/aws-vault#235 99designs/aws-vault#449

@nickatsegment
Copy link
Contributor Author

Is it worth considering rolling SAML capabilities into aws-vault?

Not a bad idea, but the genesis of aws-okta was basically a reaction to aws-vault not wanting that much scope expansion. So even if you submitted a PR, I doubt they'd want it. It's a huge maintenance burden.

@FernandoMiguel
Copy link

@nickatsegment Michael is the current maintainer of aws-vault 😉

@nickatsegment
Copy link
Contributor Author

Oh well in that case, that'd be awesome! If such a thing happened, that'd be ideal for us. We'd be happy aws-vault users (and probably contributors).

sirhc added a commit to sirhc/okta.plugin.zsh that referenced this issue Apr 15, 2020
This patch adds support for the options to the `okta-awscli` command.

<https://github.com/jmhale/okta-awscli>

Support for this command is being introduced, because the `aws-okta`
command has been put on what the author refers to as an "indefinite
hiatus."

<segmentio/aws-okta#278>
@mtibben
Copy link

mtibben commented Apr 21, 2020

Hey folks, aws-vault support for AWS SSO has just been merged in 99designs/aws-vault#549. Try out the v6 pre-release and let us know if this works for Okta using the 3rd Party IdP support

@dantrauner
Copy link

@mtibben will that only work if you use the native AWS SSO service?

@mtibben
Copy link

mtibben commented Apr 21, 2020

Yes that's correct, but my understanding is that it supports 3rd party IdP

@dantrauner
Copy link

It does, but it turns out you cannot use it if you're in a position where your account is not an Organization Master, and the Organization Master for your account cannot switch from Consolidated Billing only to "All Features" 🙁

@mtibben
Copy link

mtibben commented Apr 21, 2020

Aha. I thought there may be a catch.

@lorengordon
Copy link

Another plug for another service: https://github.com/godaddy/aws-okta-processor/

It's definitely not trying to be everything to everyone, but it does several things right that I've seen other tools struggle with:

  • Properly caches both the Okta and AWS sessions, and re-prompts only if necessary when sessions expire
  • Implements support for credential_process as the primary interface to AWS credentials
  • Supports MFA
  • Manages stdout/stderr properly such that it does not interfere with most any CLI tool built with most any SDK

@neuralsandwich
Copy link

Just to mention we maintain a fork at Five

@jspiro
Copy link

jspiro commented Feb 17, 2021

@neuralsandwich

  1. If you could summarize, what are your improvements?
  2. If it's a fork, why is it not shown as a proper fork? It looks like you cloned it and re-pushed.

@neuralsandwich
Copy link

  1. Mostly been small changes to fit our needs a bit better
  2. ¯_(ツ)_/¯ possibly but I couldn't say, we've had the repo a while

@reegnz
Copy link
Contributor

reegnz commented Mar 17, 2021

I've had pretty good success with https://github.com/Nike-Inc/gimme-aws-creds as a replacement for aws-okta. One of the major pros for me is it has a separate config, so it doesn't mix cred-tool-of-choice config with my aws configuration.

Github stars is also a good indicator that it's a popular option, hopefully not being abandoned too soon. ;)

@castrapel
Copy link

I hope it's alright to post another shameless plug!

ConsoleMe and it's CLI utility, weep use a slightly different approach (Assume role vs SSO). ConsoleMe handles the SSO auth (Okta and Auth0 have been tested). A blog post outlining how AWS credentials and self-service IAM work in ConsoleMe is here: https://netflixtechblog.com/consoleme-a-central-control-plane-for-aws-permissions-and-access-fd09afdd60a8

@rgooch
Copy link

rgooch commented Apr 23, 2021

People here may be interested in Cloud-Gate which is an access portal (Web and CLI/API) which you can tie to your IDentity Provider (IDP) of choice. It's being used and contributed to by a few companies/dedicated individuals. Access to accounts and roles is controlled via group memberships, wth support for LDAP and GitDB (record your group memberships in Git, with the approval workflows and delegation powers that you already are familiar with).

Also, if you want to maintain control over your identities, Keymaster is an IDP which provides short-lived (max 24 hours) Web Auth, SSH and X.509 certificates, brought to you by the same team. It can delegate the primary authentication to another IDP such as Okta, giving your full integration with your HRIS processes while retaining control over the minting of credentials (i.e. you are protected from Okta being pwned, for example).

These authN tools have been built from the ground up to be simple to use with a streamlined user experience, without compromising on real-life security.

These are all available under the Cloud-Founbdations umbrella.

@briantist
Copy link

For anyone who is still using aws-okta and looking for native Windows, we have a repo where we publish compiled aws-okta.exe binaries and MSI installers: https://github.com/flatironhealth/aws-okta-windows

Note that this isn't a fork and we aren't making updates or enhancements.

@nickatsegment
Copy link
Contributor Author

Hi folks, thanks for all the suggestions. It's been a year and a half now and we at Segment have moved on from aws-okta internally.

Right after this post, I'm going to archive this repo: it will receive no more updates, including security updates. Consider one of the alternatives above. It's been a gas. 👋

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests