Forum Discussion

sethraymond's avatar
sethraymond
New Contributor
3 months ago

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...
CLI
linux
1P_Phil's avatar
1P_Phil
Icon for Moderator rankModerator
2 months ago

Hi sethraymond​ ,

Have you tried having a simple script that the devs on the host machine can call.  The script then uses "op inject" into an env variable?  I use this for my scripts, here's an example usage:

env $(op inject -i ./.env.template | xargs) \
  python ./fetch_posts.py --write-output --output-file

My .env.template file is simply a file that contains references to secrets in my 1Password account.

username=op://[Vault]/[Item]/login
password=op://[Vault]/[Item]/password

Then I add this to a startup script that sets the environment variable. Once the script returns the environment variables are no longer available to the end user.

Thanks,
Phil

  • sethraymond's avatar
    sethraymond
    New Contributor
    2 months ago

    Hi 1P_Phil​ ,

    I suppose this would work to do something like

    env $(op inject -i ./.env.template | xargs) docker run -e USERNAME=$username ...

    to support the use case I have (authenticating inside of a docker container with the op CLI installed). It's not the most robust mechanism because it requires all of our developers to have their 1Password credentials named exactly the same in their Employee vault. For a bit more clarification, our process is:

    1. Log in to the op CLI
    2. Clone our repository
    3. Run the enter_docker.sh script inside the repository
      1. This script sets environment variables and bind/volume mounts appropriately for the container

    ---

    I've got a working prototype where the enter_docker.sh script does an op read op://Shared Vault/Service Account Token: builder/credential and injects that into the container as the OP_SERVICE_ACCOUNT_TOKEN environment variable. It doesn't really give us an appropriate audit trail to see who is consuming items out of the vaults (that's where the proposed socket mechanism would be nice), but it does work for the functionality we need.

    ---

    One question about service account tokens: When I call

    op read "op://Employee/Service Account Token: builder/credential"

    I get the following error:

    [ERROR] 2025/09/16 17:14:33 could not read secret 'op://Employee/Service Account Token: builder/credential': invalid secret reference 'op://Employee/Service Account Token: builder/credential': invalid character in secret reference: ':'

    The ':' character after Token is causing op read to choke. Is there a known workaround for this, or does the default name for the service account auth tokens just not compatible with the CLI? I've had to use the UUID as a reference instead, but that hurts readability.