-
Notifications
You must be signed in to change notification settings - Fork 224
ATTENTION: aws-okta is on indefinite hiatus #278
Comments
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 Personally it feels to me like everybody should probably just build their own in-house |
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 |
The brew package is maintained by non-Segmenters. So they could choose to use a new fork.
Yep, that's an idea. Someone can make an org. But I wouldn't trust that fork any more than e.g. |
Thanks for the mention @nickatsegment I have added the super handy console login option to Versent/saml2aws#410 There are some great ideas in Cheers. |
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 |
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. |
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. |
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 |
Not a bad idea, but the genesis of |
@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). |
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>
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:
|
Just to mention we maintain a fork at Five |
|
|
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 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 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. 👋 |
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.
The text was updated successfully, but these errors were encountered: