Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
Feature Request - Access vault from inside docker container
Background
At our work, we spawn a Docker container that contains the tooling required to build our Yocto-based OS image. We want to pull a key from our shared 1Password vault and inject it into our OS image. Developers all have the op plugin installed and are logged in to their accounts.
Problem
If we install the op CLI inside the Docker image, developers have to log in to their account again when they spawn the container to get access to the vault. This is cumbersome. Our workaround is to have developers run a script before spawning the container that opens the vault on their host machine, accesses the vault through the op CLI, and grabs the key. We currently write it to disk on the host and mount that into the Docker container, which is a potential security vulnerability that we'd like to avoid.
Proposed Solution
I'd like to install the op plugin into our builder Docker image and access the op CLI from the host. We can do that for things like SSH - we mount the SSH_AUTH_SOCK into the container and it just proxies requests back into the host. Could there be a domain socket for the op CLI to allow us to do something similar?
Similar Requests
Feature Request: First-Class Support for Dev Containers and 'op' CLI | 1Password Community - but not just for devcontainers, more generic.
3 Replies
- 1P_Phil
Moderator
Hi sethraymond ,
Thanks for the request.
I'm curious has the team explored using Service Accounts?
Service accounts let your container pull secrets directly from the vault in a non-interactive way. The CLI supports them out of the box, but so do the recently introduced SDKs.
Docs: https://developer.1password.com/docs/service-accounts/
SDKs: https://developer.1password.com/docs/sdks (Go, TS & Python)Let me know if this works for you.
Thanks!
Phil & the 1Password teamHi 1P_Phil , thanks for the quick reply! We do use a service account for our Jenkins integration. I'm not sure that a service account is appropriate for this use case, though. We'd have to give each of the developers either their own unique service account (not ideal), or we'd have to share the same service account token, which is also not ideal. Unless you're suggesting we build the service account token into our Docker image, which would be doable if we're extremely careful about doing that securely.
My preference would be to just be able to have developers authenticate as themselves as they go and pull secrets from the vault, but if you have a clearer picture as to how a service account could solve this problem, I'm all ears. I can also try to clarify the problem a bit more if that helps.
Hi 1P_Phil , just wanted to follow up and see if there's something about your proposed service accounts that I'm not understanding properly.
