Forum Discussion

pmdarrow's avatar
pmdarrow
New Contributor
2 months ago

Environments: any plans for CLI/API support?

Our team would love to adopt Environments but are running into some limitations:

  1. Programmatic writes to Environments
    Are there plans to support creating/updating Environments and their variables via the 1Password CLI or 1Password Connect? Currently, AWS Secrets Manager is our source of truth for application secrets and we have a Lambda job that syncs those secrets into 1Password using the 1Password CLI. We’d love to switch that sync to populate Environments, but we can’t do that (yet?) without a write API/CLI for Environments.
  2. Headless/CI usage
    We’d like to use Environments in CI. Unless I’m missing something, mounting Environments appears to be configured solely through the UI right now. Is there a way (or plan) to support Environments in CI pipelines, e.g. via a GitHub Action?

For context, today we make this work with 1Password CLI + secure notes + secret references, which is fine, but the named pipe pattern would simplify a lot of workflows for us.

Thanks!

beta environments

2 Replies

  • sid's avatar
    sid
    Icon for 1Password Team rank1Password Team
    2 months ago

    Hey pmdarrow​,

    Thanks for checking out Environments and exploring how it might fit into your team’s workflows!

    We’re looking at introducing programmatic access to Environments via the CLI and SDK down the road, so keep an eye out for future updates on that! The initial focus will likely be read-only access, but we’d love to better understand your specific use case so we can make sure we’re solving the right problems. You might hear from our team for a quick follow-up if you’re open to it.

    Regarding your point about using Environments in CI, that’s a really interesting thought. Right now, mounting Environments is primarily designed for local use (handled through the 1Password app), and when the CLI is authenticated through the desktop app, it already has access to the same FIFO mounting functionality. For headless or service-account–based workflows, SDKs or future API support would likely be a better fit. Is there a particular reason you’d like to see mounting support in headless workflows?

    • pmdarrow's avatar
      pmdarrow
      New Contributor
      2 months ago

      sid​ totally open to a follow-up and explaining our use case in more detail! You're right in that mounting in a headless workflow is not ideal and that SDKs or future API support would be a much better fit. I was just trying to think of workarounds that we could adopt to be able to start using environments today. I think our only option right now is to maintain vault items that can be accessed via the CLI w/secret references, and manually sync them to environments.