npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

okta-aws

v1.0.7

Published

Assume role into your main account with the option off assuming role into a secondary account using okta/SAML SSO.

Downloads

23

Readme

okta-aws

Assume role into your main account with the option off assuming role into a secondary account using okta/SAML SSO.

At Red Ventures we have one interesting problem. Right, just one. Go with that.

In our cloud infrastructure we need to have users. Interesting right? That's not the good part.

These users need to be controlled by single sign-on for which we use Okta. Ok Ok, I know the O word might have just turned you off on this whole thing, but bare with me.

Okta gives us SAML sometimes, when we ask nice, cross our T's, and the moon is properly lined up with Venus and Jupiter. Surprisingly this happens a lot, but you're right, still not interesting.

We want to use that SAML to Assume Role into an AWS account. Once we assume role we want to use our temporary creds to be able to run the AWS cli or our own commands that are powered by the AWS SDK. Now the good part.

We also want to be able to use those temporary creds to generate a second set of temporary creds by assuming role into another account. Go ahead, try it. I'll wait.

Or you can go ahead and use this handy little somewhat poorly written NodeJS script. Or look at my code and write it in Golang like it should have been (then send me a link to your repo so I can switch over to yours).

Requirements

If you only want to assume role into a single account, you just need the Okta base URL for your organization (https://.okta.com) and the SAML endpoint for the Okta application that is setup to log you into your initial AWS account. The SAML endpoint can be found in the admin console under the settings for the application. These will need to go in a file in your home directory called ~/.okta-aws/config that looks like this:

[okta]
baseUrl=https://<yourorghere>.okta.com/
appUrl=https://<yourorghere>/app/<my_aws_app_name>/<somekeyfromokta>/sso/saml

Installing

npm install -g okta-aws

Using with your primary account (i.e. the one you have your Okta app pointed at)

So now you want to be able to execute commands with aws-cli in your main account. Easy peasy, try this on for size:

$ okta-aws -- /bin/bash
Username:
Password:
MFA Code:
bash-3.2$

Assuming role into a second account

I think that AWS-Vault is a super fantastic tool for managing non temporary AWS keys on your local machine. If you properly setup your ~/.aws/config file you can use those keys to assume roles in the accounts where the user/keys have privileges. I wanted to use the same format for the profiles so that a single profile entry could potentially be used by AWS-Vault and okta-aws. Here is an example profile entry:

[profile mysecond-adm]
source_profile = myfirst-adm
role_arn = arn:aws:iam::<accountId>:role/<roleName>

accountId and roleName would be replaced with the info from the 2nd account/role that you are using the first role you assumed to jump in to. For our purposes here source_profile is ignored because that is set by the appUrl in the ~/.okta-aws/config file and doesn't have an effect at this stage.

Once you add the entry for you secondary profile, you can run command with it by specifying it as you 1st parameter to okta-aws

okta-aws mysecond-adm -- /bin/bash

This will get you a bash prompt with the credentials for the 2nd role generated using the credentials from the first role. Basically something like this:

okta login ->
  SAML assumeRole to role arn in okta app (first role) ->
    get creds for first role ->
      assumeRole to arn in mysecond-adm profile ->
        get creds for mysecond-adm ->
          execute command with mysecond-adm creds in environment

Debugging

I use the debug module so you can get more output along the way by running:

DEBUG=auth* okta-aws -- /bin/bash

DEBUG=* will also get you output from SuperAgent and some other modules I use.

Known issues/Areas for improvement

  • Better parsing of parameters to make adding flags doable
  • Fix the ghetto role parsing from the SAML
  • Add --help flag
  • Add some better errors when second role is denied access
  • Break index.js into a couple of smaller modules so it doesn't code smell like a stinky long file
  • Write enough unit tests so that James will let us deploy this thing. Oh, wait.