Granted CLI Workspaces

[JoshuaWilkes]

Background

Granted CLI makes working with the AWS in the browser and the terminal easy, it changed the way we work at Common Fate. Now as we are building our new products, I considered how I could extend Granted to improve more of my daily development workflow.

Proposal

My proposal is to setup what I’m calling “workspaces” for the Granted CLI which leverage the existing browser capabilities and make software development easier.

For example, Alice is a web app developer who frequently works on features that need to be tested by 2 user types, say an admin and a regular user. To test this in local dev, Alice use 2 seperate browsers, or sometimes an incognito tab, then logs into a different account on each one. This works fine, but there is a need to switch between windows, and when you close the incognito browser, the session is lost.

With “workspaces”, Granted CLI would allow Alice to run a command to automatically open Firefox with 2 containers, one for the user and one for the admin directly to the http://localhost:3000/ server that she’s developing on. After logging in once, the browser can be closed and the workspace relaunched with the user sessions persisted in each container.

Now extend this idea, [Open a CLI and a console at the same time with a one liner](common-fate/granted#280) is one suggestion. Another use case is launching multiple console sessions with a single command. You could setup a profile which assumes the developer role, exports credentials to .env and opens the console up to any relevant web pages you need for that task.

You may have an incident response workspace or observability workspace, which will open up a range of console sessions and any web apps of dashboards that you usually need in Firefox containers side by side. If you need to request access and you are using Granted Approvals, you would be given the links required to request access.

For me, it would be amazing to have a one liner, assume -w approvals-dev that

• assumed my development profile
• exported the credentials in my terminal and to my .env file
• launched the vs-code debug profile for my local backend server
• started the web server in a seperate vs-code terminal
• launched a Firefox container for
  • A regular user logged in to http://localhost:3000/
  • An admin user logged in to http://localhost:3000/
  • The AWS console open to dynamoDB for debugging

I think for convenience we should also look at adding supporting launching multiple profiles via assume e.g assume -c profile1 profile2

Proposed Commands

Launching a workspace

You should be able to launch a workspace with either granted or assume, though you need to use assume if the workspace exports credentials to the terminal environment. We could reduce this to only the assume command, however I feel like theres no reason to only have it as a flag on assume.

granted workspaces <name>

granted w <name>

assume -w <name> required for profiles which export credentials to the current terminal, but otherwise the same as the granted command

Configure a workspace

configuration should be via the TOML file and can be edited using the CLI

granted workspaces add

granted w update

granted w remove

granted w list Workspaces should be able to have descriptions

For Discussion

• I would like to hear from the community what developer productivity tool they use that fit in this space or other use-cases that we may be able to support.

[tomharrisonjr]

This proposal solves at least one of the key bits of missing functionality that I would like to see, and it's a big one/good one.

My use case of late has been developing Glue jobs (Spark), typically in the same development environment/account. I open FF using assume -s glue --region us-west-2 dev-eks1 (dev-eks1 is an AWS profile that as of last release I have augmented with the granted SSO changes. Then, I add Athena, Glue Data Catalog, Glue Crawlers, S3 to a specific bucket, and maybe CloudWatch logs, IAM and others. So this is my browser during most of my recent days.

In addition, I have command line sessions, e.g. Jupyter notebook, running AWS CLI, utilities like awslogs that get logs from Cloudwatch, and kubectl and Lens which let me view and manage my current EKS stuff. These are typically part of the work I am doing in Glue.

Current browser support is challenging in the morning after sessions have timed out. I haven't found a way to refresh the session and re-login each of the open tabs. Seems like I have to close the browser and start over with a new session. I may be missing something simple, like perhaps using the start url login in that browser.

I sometimes have to open other AWS resources in separate accounts, such as RDS, Redis, EKS in production. It feels like these want to open in a separate browser window -- I had experimented with Chrome profiles for a short time, where the profile theme was different depending on environment -- green for dev, yellow for staging, red for production. Switched between these with Command + backtick.

Meanwhile, back at the command line I have been struggling with granted. We use AWS SSO, and the permissions I have are sufficient for most of my daily needs. There are a few use-cases where I have to assume-role in order to run certain commands but mostly I am just logged in. We have and existing utility (just some shell functions) that I have been developing that does account switching, which includes:

• export AWS_PROFILE=<new-profile-for-account>
• export AWS_REGION=<region of that profile>
• export KUBECONFIG=<eks config for that account>

but not AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY or AWS_SESSION_TOKEN (except when we do need to assume-role, then the utility has an assume-role function that just does the aws sts assume-role and remembers the variables, and an unassume-role function that clears them.)

In normal usage, shortcuts from our utility like dev, stage and prod do the environment switch. They also write the current context to a central file so that if I open another terminal session that context is retained. Some other checks happen, like a background task that runs aws sts get-current-caller to see if I am still logged in. And for some sugar, this is all linked to iTerm's badge/status bar that can read the current state and display current state.

With standard AWS SSO login, we have access to all our accounts, so just setting a profile linked to that account, via env var, handles most of the command-line cases we use. Occasionally, some software or setup will also need the AWS session variables (access keys, and session token), but mostly things know to look in the ~/.aws/config for the profile specified in the env var.

With current granted login, something seems to conflict with my setup. It seems as though AWS_PROFILE and maybe AWS_REGION is ignored ... probably in favor of the access keys/session token in the environment. I haven't quite sorted out what's up, but seems like I have to run assume <profile> to get the same functionality I already have just with the standard AWS SSO login. I think the granted SSO support from v0.4.0 gets use closer.

So in this world, my wish list:

• logging in via command line would also log in the browser
• refreshing the login (e.g. in the morning after timeout) would also reactivate logged out browser sessions
• having a named granted context would open my 5 or 6 browser tabs, or refresh browser login (your proposal)
• there were a mode of granted that didn't rely on env var keys/session ... although maybe I'll just integrate granted in to the existing switcher, so possibly a moot point.

Hope this is useful feedback and context!

[chrnorm]

A tangential discussion point to add, and something I plan on raising a separate RFD for, is that it would be great to be able to use Granted for loading secrets into environment variables. For example, if MY_API_KEY is stored in AWS SSM at /secrets/my_api_key, I would love to be able to run:

granted w dev

and have MY_API_KEY exported as an environment variable (ideally at the same time as assuming the cloud role I need!).

Workspaces could also export non-secret variables, similar to @tomharrisonjr's example above exporting KUBECONFIG.

[chrnorm]

On command names, I'm for the idea of having w as a reserved argument in assume. If you're using this command, you'll be typing it a lot, so saving a keystroke on - is good IMO:

assume w <name>

If a user happens to have a profile called w, we could allow them to access it as follows:

assume _w

(and if for any reason a user happens to have a profile called _w we could allow access like this: assume "\_w")