secrets in a devcontainer setup

nyoungb2 · February 2023

I would like to use 1password in a devcontainer setup (remote machine; connected via ssh) to initialize some secrets for my developer environment. I currently have:

curl -sS https://downloads.1password.com/linux/keys/1password.asc | \
  sudo gpg --dearmor --output /usr/share/keyrings/1password-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/1password-archive-keyring.gpg] https://downloads.1password.com/linux/debian/$(dpkg --print-architecture) stable main" |
  sudo tee /etc/apt/sources.list.d/1password.list
sudo mkdir -p /etc/debsig/policies/AC2D62742012EA22/
curl -sS https://downloads.1password.com/linux/debian/debsig/1password.pol | \
  sudo tee /etc/debsig/policies/AC2D62742012EA22/1password.pol
sudo mkdir -p /usr/share/debsig/keyrings/AC2D62742012EA22
curl -sS https://downloads.1password.com/linux/keys/1password.asc | \
  sudo gpg --dearmor --output /usr/share/debsig/keyrings/AC2D62742012EA22/debsig.gpg
sudo apt update && sudo apt install 1password-cli
eval $(op signin)

...in my setup.sh that is run as part of my devcontainer setup.

However, I then have to manually sign in during the setup, which requires 4 items of information to type in, including a long secret key. After the setup is complete, I then have to sign in again via eval $(op signin) if I want to use op within my devcontainer.

Is there a better way? If yes, it would be great to have specific documentation on best-practices for using 1password with devcontainers (and remote ssh).

1Password Version: 2.13.1
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided
Referrer: forum-search:vs code

Jack.P_1P · February 2023

Hi @nyoungb2:

Great question! If you're looking to use secrets in a non-interactive flow, like remote machines, 1Password Secrets Automation might be your best bet. This would allow you to use bearer tokens to access secrets, and ensure that they're only scoped to vaults that contain the specific secrets you're looking to use on that machine. Let me know if that helps, or if you'd like to dig in a bit further.

Jack

nyoungb2 · February 2023

So there's no way to provide my sign-in address and email op signin? I always have to manually typo both when running eval $(op signin)?

I also have to get a "New 1Password sign-in from XXX" notification email every time? This gets really tedious when re-building devcontainers.

nyoungb2 · February 2023

@Jack.P_1P are there any plans on creating a 1password devcontainer feature that specifically helped automate devcontainer setup with 1password (e.g., automatically injecting 1password secrets into the postCreateCommand script for the devcontainer setup, with secrets used from the developer's local 1password app)?

nyoungb2 · February 2023

More generally, I would think that the following would work with the 1password extension:

    "containerEnv": {
        "AWS_ACCESS_KEY_ID": op://Private/AWS/username,
        "AWS_SECRET_ACCESS_KEY": op://Private/AWS/credential,
        "AWS_DEFAULT_REGION": op://Private/AWS/region
    },

but adding that to my devcontainer.json does nothing. If I run 1password: Preview with secrets, then my AWS secrets are correctly substituted in the preview, but those secrets are not substituted when I re-build my container. I also cannot hover over the op:// links and see references to the secrets, as shown in https://www.reddit.com/r/1Password/comments/vp19zy/introducing_1password_for_vs_code/.

nyoungb2 · February 2023

In regards to the "cannot hover over the op:// links" issue, I did some testing, and the hover only works for log projects, and not remote ssh connections. Maybe that is also the issue with my "containerEnv" issue. If this is the case that the 1password extension does really work for remote ssh connections, then this should be clear in the docs.

eddy_1P · May 2023

hey @nyoungb2,

First of all, thank you for your patience in getting a reply. I can imagine how it's like to spend time trying to solve your case and then wait for additional help.

I will try to respond to the things that I've identified in this thread so far to give some direction moving forward.

If I run 1password: Preview with secrets, then my AWS secrets are correctly substituted in the preview, but those secrets are not substituted when I re-build my container.

The preview just shows what the file would look like with the injected secrets in them. If you want to use the file with the injected secrets when rebuilding your container, then save the preview file and point to it when rebuilding.

Another option would be to use op inject in your rebuild script. Here's an example:

op inject -i containerEnv.json -o tmpEnv.json
# Run commands for rebiulding container and reference tmpEnv.json to use the actual secrets from 1Password
...

# Delete the resolved file since it's no longer needed
rm tmpEnv.json

However, I then have to manually sign in during the setup, which requires 4 items of information to type in, including a long secret key. After the setup is complete, I then have to sign in again via eval $(op signin) if I want to use op within my devcontainer.

So there's no way to provide my sign-in address and email op signin? I always have to manually typo both when running eval $(op signin)?

I also have to get a "New 1Password sign-in from XXX" notification email every time? This gets really tedious when re-building devcontainers.

This sounds like a use case in which Service Accounts would be more helpful for you. All you'd need to provide to your devcontainer is the OP_SERVICE_ACCOUNT_TOKEN environment variable with your service account token and then you'd be able to use the CLI in the devcontainer to create secrets in the desired vault.
Check it out and let us know if it simplifies your use case.

In regards to the "cannot hover over the op:// links" issue, I did some testing, and the hover only works for log projects, and not remote ssh connections.

The 1Password VS Code extension relies on biometrics being available on the machine the extension is called from. Therefore, I feel like it is quite unlikely to work with secrets from a remote connection. This sounds like a nice enhancement that it's worth exploring. Thank you for this feedback!

I hope that this answers most of your questions and concerns.

Feel free to reach out if you have any other issues or follow-up questions.

nyoungb2 · May 2023

Thank @eddy_1P ! Are there 1password docs with examples of setting up a VS Code devcontainer in which all secrets used in the devcontainer (e.g., AWS credentials or API keys) are all obtained from 1password upon setup of the devcontainer?

My team has resorted to using AWS Secrets Manger, since it is currently much easier for us to accomplish this goal.

secrets in a devcontainer setup

Comments