It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Feature Request: API Endpoints for 1Password Usage Reports
Today, it doesn't look possible to pull the usage reports via API. We have clients who request these reports, and having to login to each customer and manually pull the report from within the Admin portal can be very time consuming. Having the ability to pull these reports via API would speed up this process, and even allow us to schedule these reports.
Automated Connect server token rotation
I've been evaluating whether I can use 1Password Connect for configuration/secrets management for my company's services. 1Password Connect looks very appealing for several reasons: No rate limits. No usage limits. As a 1Password customer, we have unlimited access to this offering. Uniform UI. We already use 1Password for managing passwords and various secrets used during local development. It would be very nice to use the same interface to manage lifecycle of configurations and secrets that are used by production services. Pretty straightforward REST API and SDKs in languages that we use allows getting the latest config/secret values at runtime. I am not very interested in using 1Password Connect Operator (or using k8s Secrets in general) since this provides secrets to the service at deploy time. I appreciate the ability to automatically redeploy the service when the underlying 1Password item changes but this works well only for stateless services. I prefer getting configurations/secrets at runtime over an API. I started experimenting with this offering and working out how to integrate it into our systems. The docs recommend creating a Connect server token for every service which makes a lot of sense. And the docs strongly suggest setting an expiration on this token which also makes sense. After all, it's a static credential not tied to the identity of the service that uses it; so frequent rotation should reduce the risk of a leaked token causing damage. But the issue is that I don't see a way to automate this rotation given the permission model that is in use today. Is it possible for either a Service Account or a Connect client to manage connect tokens (create/delete tokens)? I was thinking of integrating 1Password connect as follows: Our deployment pipeline is high trust. It would use either Service Account or Connect client credentials that expire infrequently. It's OK for a human to ensure this credential doesn't expire and rotate it when necessary. When a service deployment is kicked off, the deployment pipeline creates a new Connect token. The pipeline ensures that the newly created Connect token is accessible to the service as an environment variable. Once the service is deployed and is considered healthy, the old Connect token (used by the previous deployment of the service) is deleted. In this setup, the deployment pipeline can create the new Connect token with a relatively short expiry and we can assume that every service gets redeployed more often than this expiration period. I think this setup is pretty reasonable but I don't see a way of giving the deployment pipeline access to create/delete Connect tokens. I tried using a Service Account to create a Connect token via the CLI and got 403. I see that it's possible to give a group access to manage Secrets Automation, but I don't think it's possible to make a Service Account a member of some group. Correct me if I am wrong. I also tried using a Connect client to create a new Connect token and this didn't work: "op connect token create" doesn't work with Connect. https://developer.1password.com/docs/connect/manage-connect of your docs mentions: "You can use 1Password.com or the https://developer.1password.com/docs/connect/api-reference/ to: ... https://developer.1password.com/docs/connect/manage-connect#create-a-token and https://developer.1password.com/docs/connect/manage-connect#revoke-a-token Connect server tokens." but I think it's a typo. As things stand today, Connect server token rotation can only be done by a human user which doesn't scale beyond a handful of services. If I were to go down that path, I would have to set expiration to a longer period which affects security. This makes 1Password Connect a lot less appealing. Please let me know if I am missing something and if there is a way to automate token rotation.
Local Environment File Partial Override and Merging
First of all I am very pleased with the announcement of the new environment feature to mount into local .env files! For our use case it would be beneficial to allow merging different environments into the same .env file or to allow partial overrides of values locally that are persisting locking of the desktop application. For local development, we have a single starter .env file with a lot of empty values and not all of these values are used by all developers. For example we have an authentication related section that contains secrets that are per-developer. For example the developer specific Github PAT, Social Auth provider App identifiers and credentials. These should be still stored in the single env file that is used during development and we would like to avoid fragmentation into multiple files at the moment, as it complicates our containerized configuration. So I have two related feature requests: Would it be possible to allow merging of different environments into a single mounted file (conflict resolution aside for now)? Would it be possible to allow partial overrides of specific values based on the employee vault or local environment?1Password Environments should enable grouping environments by service
Hi, The new .env management feature in 1Password is incredibly handy, and I can definitely see us adopting it for our backend services. It makes working with environment variables much more convenient. That said, I’d like to share some concerns regarding scalability. We have several services, each with multiple environments such as development, staging, production, and feature-specific environments. In 1Password Environments, these all of these environments appear side by side in a single list, regardless of which service they belong to. This results in naming schemes like "[Service]: [Environment]". While workable, this approach becomes harder to manage as we scale across multiple services. To illustrate, I’ve included a screenshot below showing what I anticipate the structure to look like in our setup. In this case, Service A and Service B have no relation to each other, yet their environments are intermingled. A way of grouping services would make this much clearer and easier to navigate. Best regards, Simon B. Støvring.env files should support more file formats
Hey, I was incredibly excited to see the 1Password beta supporting .env files. After testing it out in the latest beta, I understand that this is incredibly useful for environments that support traditional .env files. However, as someone working with building mobile apps, specifically for iOS, I was hoping that the new feature was a tad more flexible, enabling me to use it in .swift files. Specifically, I was hoping that the new feature would replace references to secrets in existing files rather than creating a new (temporary) file. If it were replacing references in existing files, we could use the .env support in 1Password's Environment with any file template. I understand the downsides to this, but in the mobile landscape it's not uncommon to hardcode select secrets in the binary and even when doing so, we'd like to keep those secrets out of version control. Therefore, we have .swift template files that look like this: enum Secrets { enum SomeService { static var apiKey: String { "{{ op://Acme GitHub Actions/Some Service API Key/API Key }}" } } } These files are named Secrets.tpl.swift and are stored in version control. We use `op inject` to inject the secrets into these files and output them as Secrets.swift, so they're referenced at compile time. Secrets.swift is not checked into version control, of course. I was hoping that we could mount Secrets.tpl.swift or similar in 1Password Environments to have it handle the secrets for us, as .env files aren't really a thing in iOS development. I'm excited to use 1Password Environments with the new .env files in backend development, but I hope you'll consider making it more flexible, so it can accommodate more platforms too. Best regards, Simon B. Støvring
'op read' mistreats binary content
I wanted to write a command for git crypt unlock <FILE>, but since the command requires file as input and I was figuring out how to get content of attachment, I first tried it with op read 'op://<my-vault>//git-crypt.key' > git-crypt.key. Then, trying to unlock with now stored key, I was met with error "not a valid git-crypt key file". After some investigation, I found out that the stored key is slightly modified. This seem to happen when: The content is at least partially binary The content contains some invalid Unicode sequences or certain control characters The content is directly redirected into a file using > operator It seems that ascii-only content isn't affected. The binary content is also not affected when it's being piped into another process (e.g. op read 'op://<my-vault>/<my-item>/git-crypt.key' | cat > git-crypt.key - extra cat in the pipeline helps op store the contents correctly). What also works correctly is git crypt unlock <(op read -n ...) as it also creates a inter-process pipe. Since there's quite glaring occurrence of ef bf bd, which is a Unicode replacement character (�), and sequence 594f 7f63 is transformed to just 594f 63.. (7f being a DELETE control character), it seems that the content undergoes some UTF-8 decoding/processing. This is bit confusing as it's neither documented, nor is there any -b | --binary option to control this behavior. # Create a binary file and upload it to 1Password > dd if=/dev/urandom of=binary-data bs=1 count=32 # Fetch the attachment from 1Password using CLI > op read -n 'op://<my-vault>/Test/binary-data' > binary-data-redirected-to-file > op read -n 'op://<my-vault>/Test/binary-data' | cat > binary-data-piped-through-cat # Print content > hexxy -n binary-data 0000000: 00c6 773b 1963 95f1 6dc5 1bb6 bdde 4946 ..w;.c..m.....IF 0000010: 9f0e 594f 7f63 b6ed 2392 f9e1 91b3 abfc ..YO.c..#....... > hexxy -n binary-data-redirected-to-file 0000000: efbf bd77 3b63 efbf bdef bfbd 6def bfbd ...w;c......m... 0000010: efbf bdef bfbd efbf bd49 46ef bfbd 594f .........IF...YO 0000020: 63ef bfbd efbf bd23 efbf bdef bfbd e191 c......#........ 0000030: b3ef bfbd efbf bd ....... > hexxy -n binary-data-piped-through-cat 0000000: 00c6 773b 1963 95f1 6dc5 1bb6 bdde 4946 ..w;.c..m.....IF 0000010: 9f0e 594f 7f63 b6ed 2392 f9e1 91b3 abfc ..YO.c..#....... Rant on the side: Not being able to use <code> tag on forum is bit dumb.
Search for CLI
Hi! I'd like to request a feature: For the 1Password CLI (`op`) to support searching, just like the GUI client does. My use case: I have about 30 or so entries that I would like to add a tag to. All entries belong to the same domain "home.mydomain.com" (many have subdomains on it). In the GUI client I type "home.mydomain.com" and they all come up. I want to use a script using the `op` CLI to edit each, adding a tag to them. Right now the only method I can find is to first list all items and then retrieve each and do the search myself. That's very slow. It would be great if I could send a search them off and get back a list of results. This could be as simple as `op item search "home.mydomain.com" --format=json` and then I could edit each of those items. Thanks!
Feature request: select account in `op://` url querystring
Hi there! Had a feature request I'd like to make. I have several environment variables with 1Password secret paths across a couple of accounts, some of which are in my environment only when my working directory is inside some subpath. The env vars specified in my rc files tend to be with a personal account while some of my work ones are when I'm in a work-related directory. The problem with this is that when I run `op run` (with or without an explicit `--account` specified), it fails because the paths span multiple accounts. Would be great to be able to specify the account as part of the url. Something like the following: `op://path/to/secret?account=personal` Thanks!
