Using Granted in a Dev Container

Josh Armitage
3 min readSep 22, 2023

--

As a passionate and outspoken granted.dev advocate, I was recently presented with the challenge of loading making granted work within dev containers to help further expand it’s use across our 1,000 consultants.

Unfortunately granted is not, at this point in time, a publicly provided dev container feature. Something I hope to get around to fixing once I iron out more kinks in the process.

This post is a summary of what I found in my spike, the successes, failures and issues I’m still hoping to resolve.

Step One: Installing the CLI

As it’s not a dev container feature, you will need to create a Dockerfile in your .devcontainer folder. In my spike, I used the Microsoft provided golang image: mcr.microsoft.com/devcontainers/go:1–1.21-bullseye

Which gives an initial Dockerfile of:

FROM mcr.microsoft.com/devcontainers/go:1-1.21-bullseye

# Install Granted
RUN curl -OL releases.commonfate.io/granted/v0.16.0/granted_0.16.0_linux_arm64.tar.gz && sudo tar -zxvf ./granted_0.16.0_linux_arm64.tar.gz -C /usr/local/bin/

And devcontainer.jsonof:

{
"name": "Go",
"build": {
"dockerfile": "Dockerfile"
}
}

Step Two: Adding the AWS Profiles

With the granted CLI now installed, we now need our ~/.aws directory mounting so we can get our profile configuration loaded into the dev container.

This can be achieved by extending the devcontainer.json to look like so:

{
"name": "Go",
"build": {
"dockerfile": "Dockerfile"
},
"mounts": [
"source=${env:HOME}${env:USERPROFILE}/.aws,target=/home/vscode/.aws,type=bind"
]
}

NB. ${env:HOME}${env:USERPROFILE} means that this will work for Linux, Mac and Windows systems.

Step Three: Setting Sensible Defaults

Now when we load into our dev container, assume is on our path, and we can access our list of profiles as we normally would. But every container rebuild we are presented with the initial granted configuration wizard.

This can be fixed by preloading the following config file (created in our .devcontainer folder, into the container into the ~/.granted directory.

DefaultBrowser = "STDOUT"
CustomBrowserPath = ""
CustomSSOBrowserPath = ""
Ordering = ""
ExportCredentialSuffix = ""

Which is done by updating the Dockerfile to look like:

FROM mcr.microsoft.com/devcontainers/go:1-1.21-bullseye

# Install Granted
RUN curl -OL releases.commonfate.io/granted/v0.16.0/granted_0.16.0_linux_arm64.tar.gz && sudo tar -zxvf ./granted_0.16.0_linux_arm64.tar.gz -C /usr/local/bin/

RUN mkdir /home/vscode/.granted
COPY config /home/vscode/.granted/config
RUN chown -R vscode /home/vscode/.granted

Step Four: Settings the Alias

Another initial onboarding step for using assume is the creation of the alias so we are sourcing assume to allow for the setting of environment variables in the parent shell.

This is most simply done by adding another line to our Dockerfile:

FROM mcr.microsoft.com/devcontainers/go:1-1.21-bullseye

# Install Granted
RUN curl -OL releases.commonfate.io/granted/v0.16.0/granted_0.16.0_linux_arm64.tar.gz && sudo tar -zxvf ./granted_0.16.0_linux_arm64.tar.gz -C /usr/local/bin/

RUN mkdir /home/vscode/.granted
COPY config /home/vscode/.granted/config
RUN chown -R vscode /home/vscode/.granted
RUN echo 'alias assume=". assume"' >> /home/vscode/.profile

Step Five: Assuming a Role

Now in the container, when you run assume your-role you will be prompted for a passphrase, which is blank, and then presented a URL which if traversed to on your workstation will successfully authenticate assume from within the container.

A successful flow should have console output like the following:

Step Six: Executing against AWS

Now you can authenticate against AWS by running commands such as assume <your-role> --exec <your command here>

Current Issues

Please note that I believe both the following issues are user error, and not an issue with the tool itself.

Environment Variables

To date, I have been unable to get the environment variables of the bash shell within the container to be populated correctly. Normally, by having the alias configured correctly, as in step 4, running assume will set the required environment variables for you to automatically authenticate as your chosen role.

While there are workarounds, I’ve found them hackier than using the --exec flag with assume for now.

Passphrase Requirement

Currently being prompted for a password for ~/.granted/secure-storage-aws-sso-tokens during the authentication flow is less than ideal as we are in a transitory, single tenanted environment.

Next Steps

I intend to continue to iterate on my approach of granted within a dev container, resolving both identified issues and exploring creating a publicly available dev container feature for the loading and configuration of the tool.

To follow along with my progress, feel free to drop a star on the repository here.

--

--