It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Mark environment variable value as optional
Hey community! The Environments feature came into a very fitting point for our team’s new project. We’re currently experimenting with it in order to replace the .env.template file conventionally used to denote the list of variables needed in a local dev env. There’s a small issue however (very similar use case to Tillman’s). Not all developers need all variables, and additionally there are variables that are personal to each user. So, after short experimentation we thought of the following suggestion: What if, alongside the key/value pairs that are persisted in the .env file (common for all users that have access to the .env file), there was a different entry type whose value wasn’t synced to the upstream? This way, 1. all users with access to the .env file would always have the up-to-date list of all variables used in the project, but 2. would be able to leave some values empty and let the code decide how to handle this case, and 3. would be able to add personal values (eg. API keys even via secret references) without leaking them to the rest of the users. What do you think?
1Password Environments Beta is awesome
Just wanted to drop some feedback after playing around with the new Environments Beta in 1Password. Honestly, I’m loving it so far. The local .env file mounting is just brilliant. Secrets are easy to access without having to run extra commands, but still secure – exactly what I want. Makes switching between machines seamless, too. A couple of things I’d really like to see next: 1. CLI Integration - being able to create/edit/list environments and variables from the terminal would make this so much more useful, right now, having to click around in the desktop app is a bit of a pain for dev workflows. 2. More integrations: AWS Secrets Manager is a great start, but would love to see GCP and other major providers such as GitHub, etc. A plugin system for integrations would be awesome also to help cover more niche players like Modal.com Overall, this is a huge step in the right direction for 1Password. Can’t wait to see where this goes next!
"op inject" does not find item in vault
Hi, I'm currently trying to generate a .env file locally using a .env.reference containing secret references, but I keep getting an error when running op inject. Any help on this would be much appreciated. --- .env.reference APP_ENV="op://Env_Server_Local/APP_ENV/password" FRONTEND_APP_URL="op://Env_Server_Local/FRONTEND_APP_URL/password" SERVER_URL="op://Env_Server_Local/SERVER_URL/password" > When running op read, it works % op read op://Env_Server_Local/APP_ENV/password development > When running op inject to generate the .env file, it fails. The secret does exist and was not deleted or archived. % op inject -i packages/server/.env.reference -o packages/server/.env [ERROR] 2025/06/13 08:45:14 could not find item APP_ENV in vault Env_Server_Local, because it has been deleted or archived. Please restore the item if you want to use it with secret provisioning. I feel it might be due to adding new items to the vault / updating existing items. --- 1password-cli : 2.31.1 desktop app: 1Password for Mac 8.10.80 (81080023) ---- This is blocking us from fully integrating 1password as secrets manager. Any help appreciated 🙏
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
