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

ATTENTION: aws-okta is on indefinite hiatus  #278

Closed

Description

@nickatsegment

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.

Activity

  1. marshallbrekka commented on Jan 20, 2020

    @marshallbrekka
    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.

  2. nickatsegment commented on Jan 20, 2020

    @nickatsegment
    ContributorAuthor

    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.

  3. jspiro commented on Jan 22, 2020

    @jspiro

    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.

  4. j0nathontayl0r commented on Jan 22, 2020

    @j0nathontayl0r

    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

  5. nickatsegment commented on Jan 22, 2020

    @nickatsegment
    ContributorAuthor

    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.

  6. wolfeidau commented on Jan 24, 2020

    @wolfeidau

    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.

  7. queue-tip commented on Jan 30, 2020

    @queue-tip

    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

  8. nickatsegment commented on Jan 30, 2020

    @nickatsegment
    ContributorAuthor

    Fixed! I know markdown, I swear.

  9. jeffwecan commented on Feb 4, 2020

    @jeffwecan

    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 😉.)

  10. nickatsegment commented on Feb 4, 2020

    @nickatsegment
    ContributorAuthor

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

  11. nickatsegment commented on Feb 4, 2020

    @nickatsegment
    ContributorAuthor

    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.

  12. jeffwecan commented on Feb 4, 2020

    @jeffwecan

    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!

  13. nickatsegment commented on Feb 6, 2020

    @nickatsegment
    ContributorAuthor

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

  14. 10 remaining items

  15. mtibben commented on Apr 21, 2020

    @mtibben

    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

  16. dantrauner commented on Apr 21, 2020

    @dantrauner

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

  17. mtibben commented on Apr 21, 2020

    @mtibben

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

  18. dantrauner commented on Apr 21, 2020

    @dantrauner

    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" 🙁

  19. mtibben commented on Apr 21, 2020

    @mtibben

    Aha. I thought there may be a catch.

  20. lorengordon commented on May 11, 2020

    @lorengordon

    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
  21. xlvdk commented on Feb 16, 2021

    @xlvdk

    Just to mention we maintain a fork at Five

  22. jspiro commented on Feb 17, 2021

    @jspiro

    @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.
  23. xlvdk commented on Feb 17, 2021

    @xlvdk
    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
  24. reegnz commented on Mar 17, 2021

    @reegnz
    Contributor

    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. ;)

  25. castrapel commented on Mar 29, 2021

    @castrapel

    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

  26. rgooch commented on Apr 23, 2021

    @rgooch

    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.

  27. briantist commented on May 11, 2021

    @briantist

    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.

  28. nickatsegment commented on May 17, 2021

    @nickatsegment
    ContributorAuthor

    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 join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions