It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Request for feedback: DMNO 1Password integration - env var/configuration tooling
Hello! TL;DR - If you've ever wanted to use secrets from 1Password in your JavaScript/TypeScript project without the hassle of writing custom scripts then check out our 1Password Plugin. We launched DMNO early this year and we've been continuously expanding our list of plugins and integrations. We're particularly proud of the 1Password plugin because it makes it very easy to retrieve secrets stored in 1Password and use them in your applications with minimal code. In addition to using values stored in 1Password, our plugin gives you: Coercion and validation Leak detection and prevention Log redaction and domain allow/deny lists for individual items Flexible storage in 1Password, from a single .env style blob to individual items Full TypeScript features including detailed IntelliSense docs and autocomplete Drop-in integrations for Remix, Next.js, Astro, Vite, and Node.js Best of all, it's completely free and open source. We'd love for other 1Password users to try it out. If there's a feature you want, we can probably add it for you and your team.[new tool] varlock: schema-driven env vars
TL;DR: We've launched something new, it's called varlock. It's like DMNO but simpler and easier to get started. It's built on top of the .env files you're already using. It makes them safer to use and share. We'd love your feedback. >> 🧙♂️https://varlock.dev --- We've been heads down working on the next evolution of secrets and configuration tooling building on what we've learned so far creating DMNO. If you've used DMNO, varlock will feel familiar. But instead of writing schemas in TypeScript, we've created a lightweight DSL that sits on top of your .env files. We think this allows for much simpler onboarding (and offboarding!). And because it's all based on decorators in comments, it should play nice with your existing tools. For any tools that would like to make use of this new syntax, we've also created an open specification, we call it @env-spec, and there's an active RFC if you would like to get involved. >> RFC: https://github.com/dmno-dev/varlock/discussions/17 —- So why varlock? Varlock is a suite of tools built to improve the experience of working with environment variables, both in terms of security and developer experience. It provides: Validation - catch errors in development instead of production Type-safety - improved DX via detailed IntelliSense Security - secret redaction in stdout and global console methods Environments - Compose defaults, environment-specific .env files, and local git-ignored overrides Secrets - use any third party provider that has a CLI to load values What next? We're just getting started and we have big plans to expand the feature set of varlock. Coming soon you'll see: Local override encryption via a desktop app using biometrics Shared team vaults with trustless cloud storage GitHub App to track config changes with audit trails Deeper integration with providers like 1Password If you've read this far, thank you. Please check out varlock and let us know what you think by replying to this post, or joining us on Discord. Tools like this are only as good as the community that shapes them. >> 🧙♂️https://varlock.dev Thanks ✌️
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..env accessed?: Lesson learned from a drained crypto wallet
A user on X recently lost their entire crypto wallet after installing a malicious extension in Cursor.ai. The extension accessed their .env file, extracted private keys, and sent them to an attacker’s server. The wallet was drained within 27 minutes. Sadly a hard lesson to learn from. What steps would you recommend to secure their setup? Read - https://x.com/0xzak/status/1955265807807545763?s=46&t=WQd8UVBBGk_pyHB3pNwGsA
Vulnerabilities in 1Password CLI Docker image (v2.30.3) – Request for fix timeline
Hello 1Password team, We are using the official 1password/op:2.30.3 Docker image in a SOC 2–compliant environment, and a recent security scan flagged multiple fixable vulnerabilities in the image, particularly in the 1Password CLI binary and its dependencies. Vulnerable components (all marked as fixable by our scanner): golang.org/x/crypto v0.27.0 → 1 Critical, 1 High stdlib v1.22.7 → 1 Critical, 3 Medium (likely from Go compiler) golang.org/x/net v0.29.0 → 3 Medium github.com/go-jose/go-jose/v4 v4.0.2 → 1 Medium debian/openssl / debian/glibc / gnutls28 / libtasn1-6 / perl → Multiple Medium debian/gcc-12 → 2 Low (we acknowledge these are non-fixable for now) Given that all the vulnerabilities above (except gcc-12) are marked as fixable, we would like to ask: Will these vulnerabilities be addressed in the next release of 1Password CLI and its official Docker image? Is there an estimated release date for the next version? (Optional) If some of these CVEs are considered not applicable due to usage context, could you provide clarifications for audit purposes? We greatly appreciate your help. Please let us know if there is a more up-to-date version we should use instead of 1password/op:2.30.3. Best regards,
