1password Secrets Automation Guide

Last updated: March 15, 2026

Use the 1Password CLI (op) to pull secrets directly into your shell scripts, CI/CD pipelines, and container orchestration workflows – eliminating hardcoded credentials entirely. Install it with brew install --cask 1password-cli, authenticate with op signin, and retrieve any secret using op item get "Item Name" --field password. This guide walks through environment variable injection, GitHub Actions integration, Kubernetes secrets, and security best practices for automated secret management.

Use the 1Password CLI: (op) to pull secrets directly into your shell scripts, CI/CD pipelines, and container orchestration workflows – eliminating hardcoded credentials entirely.
This guide walks through: environment variable injection, GitHub Actions integration, Kubernetes secrets, and security best practices for automated secret management.
This follows the principle: of least privilege: a CI/CD pipeline that only needs production database credentials should not have access to your entire vault.
Most CI platforms support: injecting environment variables during builds.
Personal Authentication The op: signin flow works well for local development and interactive use, but automated pipelines require a non-interactive authentication method.
Create a service account: through the 1Password web console under Integrations > Service Accounts.

Prerequisites

Before you begin, make sure you have the following ready:

A computer running macOS, Linux, or Windows
Terminal or command-line access
Administrator or sudo privileges (for system-level changes)
A stable internet connection for downloading tools

Step 1 - Install and Configuring the 1Password CLI

The 1Password CLI (op) provides a powerful way to interact with your vault from the terminal. Install it using Homebrew on macOS:

brew install --cask 1password-cli

For Linux or Windows WSL, you can download the appropriate binary from the 1Password GitHub repository. After installation, sign in to your account:

op signin

This command initiates an authentication flow that opens your default browser. Once authenticated, you can start retrieving secrets programmatically.

Service Accounts vs. Personal Authentication

The op signin flow works well for local development and interactive use, but automated pipelines require a non-interactive authentication method. 1Password Service Accounts provide a token-based authentication mechanism designed for this purpose.

Create a service account through the 1Password web console under Integrations > Service Accounts. Each service account gets a scoped token with access limited to specific vaults. This follows the principle of least privilege: a CI/CD pipeline that only needs production database credentials should not have access to your entire vault.

Authenticate using a service account token
export OP_SERVICE_ACCOUNT_TOKEN="ops_your_token_here"
op item list  # no interactive signin needed

Store the service account token in your CI platform’s secrets management (GitHub Actions secrets, AWS Secrets Manager, etc.) and inject it as an environment variable. Never hardcode the token in pipeline definition files or Dockerfiles.

Step 2 - Retrieve Secrets in Scripts

The fundamental operation involves fetching individual items from your vault. The basic syntax uses the item name or UUID:

Retrieve a password for a specific item
op item get "Database Password" --field password

Get a specific field from an item
op item get "AWS Production" --field "API Key"

For more complex scenarios, you can output items as JSON for parsing:

op item get "Production API Keys" --format json

This JSON output integrates cleanly with shell scripts using tools like jq:

#!/bin/bash
API_KEY=$(op item get "API Gateway" --field "client_secret" --format json | jq -r '.value')
export API_KEY

Using Secret References

1Password CLI v2 introduced secret references, an URI scheme that lets you reference vault items without calling the CLI at script time. The format is:

op://vault-name/item-name/field-name

These references work with op run, which resolves all secret references in a subprocess’s environment before starting the process:

Set environment variable using a secret reference, then run the app
op run --env-file=.env.1p -- node src/index.js

The .env.1p file contains secret references rather than actual values:

DATABASE_PASSWORD=op://Production/PostgreSQL/password
STRIPE_KEY=op://Production/Stripe/secret_key

This approach is safer than shell-level variable exports because the secrets are only exposed to the child process, not to the parent shell or its history.

Step 3 - Environment Variable Integration

One of the most practical applications involves loading secrets as environment variables before running applications. Create a script that sources your secrets:

#!/bin/bash
load-secrets.sh

Authenticate if needed
if ! op account get > /dev/null 2>&1; then
    op signin
fi

Export secrets as environment variables
export DATABASE_PASSWORD=$(op item get "PostgreSQL" --field password)
export STRIPE_API_KEY=$(op item get "Stripe" --field "secret_key")
export JWT_SECRET=$(op item get "JWT Signing" --field password)

Run your application with these secrets loaded:

source ./load-secrets.sh && node src/index.js

This approach keeps secrets out of your shell history and process listings while maintaining a clean workflow.

Step 4 - Configure CI/CD Pipeline Integration

Continuous integration environments require secure secret handling. Most CI platforms support injecting environment variables during builds. Here’s how to integrate 1Password with GitHub Actions:

name: Deploy Application

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Install 1Password CLI
        run: |
          curl -sSf https://app-updates.agilebits.com/product_history/CLI2 | \
          grep -E "op_.*\.pkg" | head -1 | \
          awk -F'{print $4}' | \
          xargs -I {} brew install {}

      - name: Sign in to 1Password
        run: echo "$OP_SERVICE_ACCOUNT_TOKEN" | op signin --stdin
        env:
          OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}

      - name: Retrieve secrets
        run: |
          echo "DB_PASSWORD=$(op item get ProductionDB --field password)" >> $GITHUB_ENV
          echo "API_KEY=$(op item get APIKeys --field api_key)" >> $GITHUB_ENV

      - name: Run deployment
        run: ./deploy.sh

Using a service account token provides granular access control without exposing your master password in CI environments.

GitLab CI Integration

For GitLab pipelines, the pattern is similar but uses GitLab’s CI variables system:

deploy:
  image: ubuntu:22.04
  script:
    - curl -sS https://downloads.1password.com/linux/debian/amd64/stable/op_2.x.x_amd64.deb -o op.deb
    - dpkg -i op.deb
    - export DB_PASSWORD=$(OP_SERVICE_ACCOUNT_TOKEN=$OP_TOKEN op item get ProductionDB --field password)
    - ./deploy.sh
  variables:
    OP_TOKEN: $OP_SERVICE_ACCOUNT_TOKEN

Define OP_SERVICE_ACCOUNT_TOKEN as a masked and protected CI/CD variable in your GitLab project settings. Masking prevents the token from appearing in job logs even if a script accidentally prints all environment variables.

Step 5 - Kubernetes and Docker Secrets

Containerized applications benefit from proper secret management. You can inject 1Password secrets into Kubernetes using external secrets operators, or simply mount secrets at runtime:

#!/bin/bash
generate-kubernetes-secrets.sh

kubectl create secret generic app-secrets \
  --from-literal=db-password=$(op item get Database --field password) \
  --from-literal=api-key=$(op item get APIKeys --field key)

For Docker Compose, reference environment files loaded through 1Password:

version: '3.8'
services:
  web:
    image: your-app:latest
    env_file:
      - .env.production
    # ...

Generate your .env.production file using a similar sourcing approach described earlier.

Step 6 - Work with Custom Fields

1Password items support custom fields beyond the standard username, password, and URL. This proves invaluable for storing multiple credentials or metadata:

List all fields for an item
op item get "Server Credentials" --format json | jq '.fields[]'

Access a specific custom field
op item get "Server Credentials" --field "ssh_private_key"

Custom fields enable organizing complex credential sets, such as multiple API keys for different environments, within a single vault item.

Security Best Practices

When automating secret retrieval, follow these essential practices:

Use service accounts instead of master passwords in automated environments. Service accounts provide limited access appropriate for CI/CD while avoiding credential exposure.

Set vault timeouts to automatically lock your vault after periods of inactivity. Configure this in your 1Password settings.

Audit access regularly using 1Password’s built-in audit logs. Monitor which secrets were accessed and from which locations.

Rotate credentials periodically even when using a password manager. Automated rotation scripts can help maintain security hygiene:

#!/bin/bash
rotate-api-key.sh

NEW_KEY=$(openssl rand -base64 32)
op item edit "API Keys" "api_key=$NEW_KEY"
Trigger your application's key update mechanism
curl -X POST https://yourapp.com/admin/rotate-key -d "key=$NEW_KEY"

Detecting Secret Exposure

Even with disciplined secret management, credentials occasionally leak through logs, error messages, or misconfigured services. Integrate secret scanning into your pipeline to detect exposures early:

Enable GitHub’s secret scanning and push protection features on all repositories
Use trufflehog or gitleaks in pre-commit hooks to prevent accidental secret commits
Monitor 1Password’s activity log for unusual access patterns, a service account accessing dozens of vaults it has never touched before is a strong indicator of token theft

If a secret is exposed, revoke it immediately through 1Password and the credential provider (AWS, Stripe, etc.), then audit logs to determine what was accessed with the exposed credential.

Troubleshooting Common Issues

Authentication failures often stem from session expiration. The CLI caches credentials temporarily, re-authenticate when needed:

Check current authentication status
op account get

Sign out and back in if needed
op signout
op signin

Permission errors indicate the service account or account lacks access to specific vaults. Verify vault access through the 1Password admin console.

If op run fails with a secret reference error, verify the vault name, item name, and field name exactly match what is stored in 1Password. Names are case-sensitive. Run op item list --vault="Production" to confirm the exact item names, and op item get "Item Name" --format json | jq '.fields[].label' to list available field labels.

Network errors in CI environments often indicate a firewall or proxy blocking outbound connections to 1Password’s API endpoints (op-connect.1password.com on port 443). Whitelist this domain in your network egress rules if you operate a restricted CI environment. Alternatively, deploy a 1Password Connect server inside your network to proxy requests through an internal endpoint, eliminating direct internet dependency for secret retrieval during builds.