1Password/Dev/Doc/Guide/Load Secrets/Into Scripts

• Load secrets into scripts | 1Password Developer

  • You can use the following methods to load secrets into scripts, separately or in combination:
    • 1Password/Dev/op/run
      • Use op run to load secrets into the environment.
    • 1Password/Dev/op/read
      • Use op read to read secrets.
    • 1Password/Dev/op/inject
      • Use op inject to load secrets into a config file.
    • 1Password/Dev/op/plugin/run
      • Use op plugin run to load secrets using a shell plugin.

  • 1Password #Tip recommends using 1Password Service Accounts instead of the above methods, but that's only realistic if you're explicitly enabled to do that by an admin on the business tier

    • We recommend using 1Password Service Accounts to follow the principle of least privilege. Service accounts support restricting 1Password CLI to specific vaults, so that processes in your authorized terminal session can only access items required for a given purpose. Service accounts are also useful if your personal account has SSO or MFA requirements.
      

      • My Note - #Important - while this page recommends using service accounts over using 1Password/Dev/op, only some people can use them
        • • 1Password/Dev/Doc/service-accounts/Manage/creating service accounts
            • By default, only owners and administrators can create and manage service accounts in 1Password/Teams and 1Password/Business.
            • To allow other groups to create service accounts, an owner or administrator can allow certain 1Password/Business/Groups to be able to manage service accounts.

  • Option 1 - use 1Password/Dev/op/run to load #Secrets into EnvVars

    • #Example

      • Given a .env File
        • bash

          AWS_SECRET_ACCESS_KEY=op://prod/aws/secret-key
          AWS_ACCESS_KEY_ID=op://prod/aws/access-key

      • op run --env-file yourscript.env -- yourscript.sh
      • This might work well with mise/Task definitions

  • Option 2 - use 1Password/Dev/op/read to read secrets in a script

    • My Notes

      • Not as useful, because it prevents the application from being used in contexts that don't use one password. Once you have a script that references op inline, every person or environment running that script must use op. Even so, there may be some use cases.

    • Directly in script

      • #Example

        • bash

          #!/bin/bash
          
          docker login -u $(op read op://prod/docker/username) -p $(op read op://prod/docker/password)

    • With environment variables

      • #Example

        • bash

          #!/bin/bash
          
          export AWS_SECRET_ACCESS_KEY=$(op read op://prod/aws/secret-key)
          export AWS_ACCESS_KEY_ID=$(op read op://prod/aws/access-key-id)
          aws sts get-caller-identity

  • Option 3 - use 1Password/Dev/op/inject to load secrets into a config file

    • If your script uses a configuration file, you can Templat/e the config file with 1Password Secret References, then use op inject to pass the config file with the resolved secrets to your script at runtime.
    • This allows you to check config files into source control and keep them in sync throughout developer workstations, CI, and production servers. And you can include template variables within the secret references to load different sets of secrets for different environments.
    • Learn how to load secrets into config files.
    • My Notes on option 3
      • This uses a specific Templat/e sytax reminiscent of Jinja - see 1Password/Dev/CLI/Ref/Concept/Template Syntax
        • • Here's an #Example of a 1Password/Dev/CLI/Template File with enclosed secret references in place of the plaintext secrets: - config.yml.tpl
            • yaml

              database:
                host: localhost
                port: 5432
                username: {{ op://prod/database/username }}
                password: {{ op://prod/database/password }}

      • of course, now you have the secret sitting around unencrypted on disk, which goes against Security/Quest/Zero Secrets on Disk
      • rant about this part

        • keep them in sync throughout developer workstations, CI, and production servers
          

        • in practice, it seems like this would likely either involve using 1Password/Dev/Connect Server or 1Password Service Account, which isn't applicable to all setups

  • Option 4 - use 1Password/Dev/op/plugin/run to load secrets using a 1Password/Dev/CLI/Shell Plugin

    • 1Password Shell Plugins prompt each user to select their credentials when the script is executed.
    • to authenticate an individual command, wrap the command in op plugin run.

      • #Example - use 1Password/Dev/CLI/Shell Plugin/AWS to provide an AWS/EnvVar AWS Access Key and Secret Key ID

        • to the  AWS/CLI/sts/get-caller-identity sts get-caller-identity command:
          • bash

            #!/bin/bash
            
            op plugin run -- aws sts get-caller-identity

    • To use a shell plugin throughout a script, you can include an alias for the tool's executable command at the beginning of the script. For example, in this script, the AWS shell plugin would be used to supply secrets for every aws command in the script.
      • bash

        #!/bin/bash
        
        alias aws="op plugin run -- aws"
        aws sts get-caller-identity

    • If a shell plugin doesn't exist for the tool you're using, you can build a new plugin.
    • My Notes
      • This might work well with mise/Task definitions