ATTENTION: aws-okta is on indefinite hiatus
nickatsegment opened this issue ยท 36 comments
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.
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.
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.
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.
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
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.
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.
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
Fixed! I know markdown, I swear.
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 ๐.)
@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.
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.
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!
Yeah, I suppose if we just did a copy instead of transfer, we'd lose all the tickets.
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
@eldondevat: I provisioned https://github.com/aws-okta/ the other day after we chatted about it here. Happy to add anyone else as collaborators to that organization if folks want to start making contributions to that fork.
Yeah, @nickatsegment @jeffwecan I don't even see a way to create issues on /aws-okta/aws-okta as-is
@eldondevat: I've toggled on the "Issues" feature for https://github.com/aws-okta/aws-okta now. ๐
๐ to keeping aws-okta alive in some form. We rely on it for important workflows and it has no match in terms of features and ease-of-use (sorry saml2aws). We're hoping we have the skill set to at least maintain the current functionality.
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
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.
@nickatsegment Michael is the current maintainer of aws-vault ๐
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).
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
Yes that's correct, but my understanding is that it supports 3rd party IdP
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" ๐
Aha. I thought there may be a catch.
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_processas 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
Just to mention we maintain a fork at Five
- If you could summarize, what are your improvements?
- If it's a fork, why is it not shown as a proper fork? It looks like you cloned it and re-pushed.
- Mostly been small changes to fit our needs a bit better
- ยฏ_(ใ)_/ยฏ possibly but I couldn't say, we've had the repo a while
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. ;)
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
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.
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.
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. ๐