It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
CLI Slow Performance
I have the 1Password desktop app installed and up to date on my macBook Pro, the `op` CLI is also installed, up to date, and working properly. All expected CLI queries work but they are surprisingly slow. After a bunch of trial and error, it seems that it is making a round-trip online as part of every single CLI query. I added the --debug flag and I can see cache hits, but the round trip online is still occurring. Disabling the network interface causes all queries to fail. Is it possible to get the 1Password CLI working fully offline to avoid all of this unnecessary round-trip business? Surely with the desktop app installed and CLI integration turned on, there has to be a way to make efficient (and offline) use of my 1Password vaults. Otherwise automation tasks that require secrets are simply too cumbersome to handle with 1Password, and I will require a secondary solution. And in that case, I may as well give up on 1Password.
Terraform plugin troubleshooting
I am troubleshooting some credential issues with the 1Password CLI terraform plugin. The plugin is in beta, I use `op` version `2.31.1-beta.01` as the latest beta version with the plugin at the time. Issue: the terraform output command does not get credentials. Baseline execution, credentials defined in environment, export AWS_ACCESS_KEY_ID="..." export AWS_SECRET_ACCESS_KEY="..." terraform init # works terraform apply # works terraform output # works unset AWS_ACCESS_KEY_ID="..." unset AWS_SECRET_ACCESS_KEY="..." Executing using the same credentials but stored in 1Password: op plugin init terraform # Choose key from 1Password op plugin run -- terraform init # works op plugin run -- terraform apply # works op plugin run -- terraform output # Error: No valid credential sources found The expected behaviour is that terraform output also works. Here's an example Terraform script that I used for testing: terraform { required_version = ">= 1.9.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 6.0" } } backend "s3" { bucket = "something-something-terraform-prod" key = "test/terraform.tfstate" region = "eu-central-1" use_lockfile = true encrypt = true } } provider "aws" { alias = "bootstrap" region = "eu-central-1" } data "aws_caller_identity" "current" { provider = aws.bootstrap } provider "aws" { region = "eu-central-1" assume_role { role_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/terraform-prod" } } data "aws_key_pair" "test" { key_name = "test-key-that-already-exists" } output key { value = data.aws_key_pair.test.key_name } Note that I use "assume-role" in the script, but this had no issues when using environment variables. I did NOT request a session token manually. I let terraform do the session management itself. The AWS provider is a bit overcomplicated, but this is what I had at hand. Terraform output works when using environment variables, and does not work when using the 1Password plugin. I ran terraform with trace level logs. I compared a working and a non-working log and the only difference is one line: 2025-09-19T21:14:32.935+0200 [TRACE] Meta.Backend: BackendOpts.Config not set, so using settings loaded from provider.tf:11,3-15 This makes me assume that the plugin does not hand over credentials to terraform when the "output" command is run. Since the state file can be stored on S3, credentials are essential for the output command. For completeness sake, here's the non-working log (with some redactions): 2025-09-19T21:14:32.934+0200 [INFO] Terraform version: 1.13.2 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/hashicorp/go-tfe v1.74.1 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/hashicorp/hcl/v2 v2.24.0 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/hashicorp/terraform-svchost v0.1.1 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/zclconf/go-cty v1.16.3 2025-09-19T21:14:32.934+0200 [INFO] Go runtime version: go1.24.5 2025-09-19T21:14:32.934+0200 [INFO] CLI args: []string{"terraform", "output"} 2025-09-19T21:14:32.934+0200 [TRACE] Stdout is a terminal of width 144 2025-09-19T21:14:32.934+0200 [TRACE] Stderr is not a terminal 2025-09-19T21:14:32.934+0200 [TRACE] Stdin is a terminal 2025-09-19T21:14:32.934+0200 [DEBUG] Attempting to open CLI config file: /Users/user/.terraformrc 2025-09-19T21:14:32.934+0200 [DEBUG] File doesn't exist, but doesn't need to. Ignoring. 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory /Users/user/.terraform.d/plugins 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory /Users/user/Library/Application Support/io.terraform/plugins 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins 2025-09-19T21:14:32.934+0200 [INFO] CLI command args: []string{"output"} 2025-09-19T21:14:32.935+0200 [TRACE] Meta.Backend: BackendOpts.Config not set, so using settings loaded from provider.tf:11,3-15 2025-09-19T21:14:32.936+0200 [TRACE] Meta.Backend: built configuration for "s3" backend with hash value 3136668788 2025-09-19T21:14:32.936+0200 [TRACE] Meta.Backend: working directory was previously initialized for "s3" backend 2025-09-19T21:14:32.936+0200 [TRACE] Meta.Backend: using already-initialized, unchanged "s3" backend configuration 2025-09-19T21:14:32.936+0200 [TRACE] backend-s3.aws-base: Resolving AWS configuration: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [DEBUG] backend-s3.aws-base: Resolving credentials provider: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [TRACE] backend-s3.aws-base: Building default HTTP client: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [DEBUG] backend-s3.aws-base: Loading configuration: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [DEBUG] backend-s3.aws-base: Retrieving credentials: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate ^[[31m╷^[[0m^[[0m ^[[31m│^[[0m ^[[0m^[[1m^[[31mError: ^[[0m^[[0m^[[1mNo valid credential sources found^[[0m A few questions in random order: Did anyone else experience similar behaviour? Is there a ticketing system where I can open an issue? Can anyone else reproduce the issue? Is there a known solution? Is there anything else I can do to provide information that could help solve this?
Service Account Security (feature request)
I just started using service accounts, so forgive me if this has already been discussed. I did not find anything while searching the forum. A few things that would greatly improve the security of service accounts from the top of my head: IP-limits for access Alerts (watchtower?) for unauthorized access attempts I think there should be a way to limit service account access to only certain IP-addresses and environments. My proposal is a combination of pre-defined environments (maintained by 1Password) like AWS region XXX, AWS region YYY ... Lists publicly available here: https://ip-ranges.amazonaws.com/ip-ranges.json Github Actions, Github Copilot ... Lists publicly available here: https://api.github.com/meta Other relevant environments you can think of And one should obviously also be able to create private lists of IP-addresses/prefixes (both IPv4 and IPv6) that can be allowed to use a certain service account. This will seriously limit the amount of damage that can happen IF (when) a service account token is leaked somewhere. When this is in place, watchtower (or similar functionality) should be able to alert you if someone tries to use a service account from outside the limited environments where it is allowed to be used. That way, you will immediately be notified if a token might be compromised, and can rotate it. Of course, if you have limited a service account to only be used from a github action, and the evil hacker also uses a github action to access your secrets, you will not know - but that is no worse than the current situation. In best case, the evil perpetrator will test the token from an invalid location first, so you will be notified and can hopefully act before any other secret data has been compromised.
opx - A 1Password companion CLI
Hello folks 👋 opx is a little tool I built so I could just opx nodejs apps and have it load secrets from 1password CLI. 1P_Phil said I should share it with the community 😀. I haven't worked on it that much recently but it does work for my use case. Ideally the following would be things i'd want to see happen with this tool. 1password take it over officially and ship more than just nodejs support if not, community helps out to add new features or bug fixes Thanks for taking a look and hoping it interest or inspires people.[GUIDE] 1Password Runtime Secret Injection for Azure Container Apps
This guide outlines a streamlined way to inject environment variables stored as secret reference URIs from 1Password into an Azure Container App (ACA) at runtime. It removes the need for init containers or writing secrets to disk. By using an ACA Command override, you can fetch a .env file saved as a Document type in 1Password, which contains the secret reference URIs, and load it straight into your container's environment. Step 1: 📃Store Your Environment File in 1Password Start by saving your environment file (e.g., .env.production), with variables encoded as secret reference URIs, as a Document type item in a 1Password vault accessible to your Service Account. This allows the 1Password CLI to read the file's contents directly. Step 2:🐳Update Your Dockerfile The Docker image must have Bash and the 1Password CLI available for the ACA Command/Arguments override to work properly. You can add the 1Password CLI using a multi-stage Dockerfile to keep your final image lean. Example FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base WORKDIR /app # Set non-root user for security USER app FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build WORKDIR / # Copy configuration files COPY ["*.json", "*.props", "*.config", "*.sln", "./"] # Copy source code COPY ./src /src # Change to source directory WORKDIR /src # Restore packages directly for the Web API project (this pulls in all dependencies) RUN dotnet restore "./Presentation/Web.Api/Web.Api.csproj" RUN dotnet build "./Presentation/Web.Api/Web.Api.csproj" -c Release RUN dotnet publish "./Presentation/Web.Api/Web.Api.csproj" -c Release -o /app/publish /p:UseAppHost=false # This stage pulls 1Password CLI (from official image) FROM 1password/op:latest AS opcli # Final image (runtime) FROM base AS final WORKDIR /app # Copy the published app COPY --from=build /app/publish . # Copy the 1Password CLI binary from the opcli stage COPY --from=opcli /usr/local/bin/op /usr/local/bin/op # Allow for replacement of the container run command. # This will allow op run --env-file <(op read "op://[vault]/[item]/[env_filename]" ) -- dotnet Web.Api.dll CMD ["dotnet", "Web.Api.dll" ] Key Points Using CMD in your Dockerfile is crucial, as Azure Container Apps only allow CMD override, not ENTRYPOINT. This example uses a .NET base image, but you can adapt it to any base image (Node, Python, etc.). Step 3:⚙️Configure Your Azure Container App Now, configure your Azure Container App to use the 1Password CLI to inject the secrets before your application starts. Service Account Token Secret: In your Container App's settings, navigate to Security/Secrets: Create a new secret named op-service-account-token ACA requirement: The key must consist of lower case alphanumeric characters and '-', and must start and end with an alphanumeric character. Paste your 1Password Service Account Token as the value. Service Account Token Environment Variable: In your Container App's settings, navigate to Application/Containers: Switch to the "Environment variables" tab and +Add a variable: Name: OP_SERVICE_ACCOUNT_TOKEN Source: "Reference a secret" Value: op-service-account-token secret created in the previous step. Container Override: In the same container settings, update the following to override the container runtime environment: Command override: /bin/bash Arguments override: -c, op run --env-file <(op read "op://[VAULT_NAME]/[ITEM_NAME]/[ENV_FILENAME]") -- [your_container_start_command] Example If your vault is named prod-env-Secrets-Vault, the 1Password item is MyWebApp, the file is .env.production, and your original container command was dotnet Web.dll, the ACA Arguments override would be: -c, op run --env-file <(op read "op://prod-env-Secrets-Vault/MyWebApp/.env.production" ) -- dotnet Web.dll This one-line command handles everything: op run --env-file parses secret reference URIs stored in the env-file provided by <(op read..), and -- then launches your application with those secrets injected into the shell environment. See: Secret Reference URIs: https://developer.1password.com/docs/cli/secret-references/ Service Account: https://developer.1password.com/docs/service-accounts/use-with-1password-cliOpenAI API Keys... Oh mai
Just a heads up, on Github, a crafty person created a query to find OpenAI API keys via search. I'm not going to link to it, but here are some resources if you fall into this camp! We have an entire blog post from 2023 about this topic https://blog.1password.com/openai-chatgpt-exposed-api-keys/ AI Agents + 1Password (Blog) https://developer.1password.com/docs/sdks/ai-agent CLI https://developer.1password.com/docs/cli/secret-references SDK (Python, Go & Typescript/JS) https://developer.1password.com/docs/sdks/load-secrets GitHub Actions with 1Password (hide API keys in CI/CD) https://developer.1password.com/docs/ci-cd/github-actions
1password pulumi provider
I see that 1password has made a pulumi provider at https://github.com/1Password/pulumi-onepassword Is this considered ready for public consumption yet? We have a couple of 1000 of auto-generated passwords that I would very much like to make available in 1password rather than out own shitty security™. However considering the importance of the data I would rather ask before accidentally getting the entire company locked out of our own production environments :D 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided Browser: Not Provided
Announcing op-python and ivorynomad.onepassword
I've created a python module intended to ease use of 1password CLI in CI/CD and IaC environments. https://pypi.org/project/op-python/ I've also created an ansible lookup plugin which leverages the op-python module to perform secrets retrieval for ansible playbooks. https://galaxy.ansible.com/ui/repo/published/ivorynomad/onepassword/ I use these in my home lab environment where they have been useful to me; I hope they might be useful for others.
