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

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.

@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)?

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/.

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.

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 https://developer.1password.com/docs/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.

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.