You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 18, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on May 18, 2021. It is now read-only.
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.
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.
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.
@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 ☺.
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" 🙁
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. ;)
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.
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. 👋
Activity
marshallbrekka commentedon Jan 20, 2020
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 commentedon Jan 20, 2020
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-oktawould just be a wrapper around thepkgs ofsaml2awsor 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 commentedon 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 commentedon Jan 22, 2020
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 commentedon Jan 22, 2020
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.
github.com/rando_calrissian/aws-oktaunless it had some elaborate foundation behind it or something.wolfeidau commentedon Jan 24, 2020
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-oktawhich I am hoping to adapt to saml2aws especially some of the caching and security features.Cheers.
queue-tip commentedon Jan 30, 2020
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 commentedon Jan 30, 2020
Fixed! I know markdown, I swear.
jeffwecan commentedon Feb 4, 2020
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 commentedon 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-oktaorg and repo and copy the history there. I.e., technically, I'm not sure you need my sign-off.nickatsegment commentedon Feb 4, 2020
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-oktamakes it seem like there's some sort of foundation behind it.jeffwecan commentedon Feb 4, 2020
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 commentedon Feb 6, 2020
Yeah, I suppose if we just did a copy instead of transfer, we'd lose all the tickets.
10 remaining items
mtibben commentedon 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 commentedon Apr 21, 2020
@mtibben will that only work if you use the native AWS SSO service?
mtibben commentedon Apr 21, 2020
Yes that's correct, but my understanding is that it supports 3rd party IdP
dantrauner commentedon Apr 21, 2020
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 commentedon Apr 21, 2020
Aha. I thought there may be a catch.
lorengordon commentedon May 11, 2020
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:
credential_processas the primary interface to AWS credentialsxlvdk commentedon Feb 16, 2021
Just to mention we maintain a fork at Five
jspiro commentedon Feb 17, 2021
@neuralsandwich
xlvdk commentedon Feb 17, 2021
reegnz commentedon 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 commentedon Mar 29, 2021
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 commentedon 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 commentedon May 11, 2021
For anyone who is still using
aws-oktaand looking for native Windows, we have a repo where we publish compiledaws-okta.exebinaries and MSI installers: https://github.com/flatironhealth/aws-okta-windowsNote that this isn't a fork and we aren't making updates or enhancements.
nickatsegment commentedon May 17, 2021
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-oktainternally.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. 👋