Forum Discussion

Former Member's avatar
Former Member
5 years ago

[21] Conditionnal injection (jinja?)

Hi CLI-team,

First of all, thanks for the CLI. v1 already changed our way of working at Cortexia.
Thanks for the v2 which allows us to already clean and consolidate our scripts by simply upgrading to v2.
And thanks for allowing us to test and share with you ;)

Secondly, I have a question / suggestion :)

How about allowing some "Jinja-ness" in the injection templating process ? Like in https://jinja.palletsprojects.com/en/3.0.x/

That would be of course a lot "in" for one shot.
But a first step that would cover my use case would be to "only" get conditional directives.

My use case is the following: I generate .env files from the values in some 1password items (similar example than the one in the doc)


DB_HOST={{ op://app/db/host }}
DB_PASSWORD={{ op://app-prod/db/password }}
...

In my use case, I also have default values in my application, e.g. db_host=xxx

With my current usage of v1, I do the following checks in my scripts when I generate my .env file (pseudo-code)


if 'db_host' in one_password_item.fields:
print("DB_HOST={one_password_item.fields.db_host}", ".env")
print("DB_PASSWORD={{ one_password_item.fields.db_password }}", ".env")
...

The output can be


DB_HOST=xxx
DB_PASSWORD=password
...

or, when using default values from the app (not having any value defined in the 1password item):


DB_PASSWORD=password
...

what I would not like to have is


DB_HOST=
DB_PASSWORD=password
...

because with the empty declaration above, the natural behavior of my app would be to override the default db_host=xxx with an empty value from the .env file

Hence the suggestion for conditional injection, or better, jinja-ness ;)

Take care,
Emmanuel

1Password Version: 7.9.2
Extension Version: 2.0.0-beta.6
OS Version: macOS 11.6

cli

8 Replies

  • Sadia_A1P's avatar
    Sadia_A1P
    Icon for 1Password Team rank1Password Team
    4 years ago

    Hi @ebreton ,

    Thank you for following up, very excited to speak with you soon!

    Best,
    Sadia

  • Former Member's avatar
    Former Member
    4 years ago

    Hi @"Sadia.Azmal_1P" , thanks a lot for your message. I have used the calendy link. I think Denis has received the invitation :)

    Bests,
    Emmanuel

  • Sadia_A1P's avatar
    Sadia_A1P
    Icon for 1Password Team rank1Password Team
    4 years ago

    Hi @ebreton ,

    I'm Sadia, a Product Manager at 1Password, and have some news that may be interesting to you. I am looking for some developers and administrators that would be interested in chatting with me about a new feature our team has been working on: Service Accounts. Earlier this year, we introduced the CLI 2.0, where users can use “run” and “inject” commands to substitute secret references for secrets stored in 1Password vaults. With our new Service Account capabilities, organizations can use a separate non-user account to control and manage access to secrets without deploying additional services like Connect.

    We are currently building out service accounts and want to understand your pain-points and experiences with secrets management, and gather some feedback, so we could deliver the best product for our customers.

    If you are interested, please feel free to reach out to me at sadia.azmal@agilebits.com or sign-up for a 30 minute slot on Calendly. I look forward to hearing from you :)

  • Former Member's avatar
    Former Member
    4 years ago

    Hi Simon,

    yes, service accounts could work here :)

    Bests,
    Emmanuel

  • 1P_Simon's avatar
    1P_Simon
    Icon for 1Password Team rank1Password Team
    4 years ago

    Hi Emmanuel,

    Thank you for providing extra details! I love figuring this out together.

    they do not need any more human attendance

    We're considering to add service accounts. They'd represent machine access to 1Password and not require human attendance. To allow the container on the edge device to authenticate as the service account and be able to decrypt the secrets, you'd add a service account credential on the device. You'd be able to set access controls on the service account just like you currently can for user accounts, so that you can limit the vaults the service has access to to apply the principle of least privilege.

    Would this work for your use case?

    Cheers,
    Simon

  • Former Member's avatar
    Former Member
    5 years ago

    Hi Simon!

    Thanks for your input, it's good to think over it from a different perspective.

    op run ... script is not an option for us because script is run within a container on an edge device (no one is going to provide the 1password needed to run the CLI)

    To give you a bit more of context: we use the CLI in our factory setup process to prepare the containers: they ship in all the env variables and here they go... they do not need any more human attendance ;) Therefore we are definitively good clients for the op inject command

    My next step will be to fill the 1Password items with the default values as a pre-process step. That will allow the factory setup to get a value in all cases. And I will think on using variables within the injected document. See how it could help.

    Thanks again for your answer,
    Emmanuel

  • 1P_Simon's avatar
    1P_Simon
    Icon for 1Password Team rank1Password Team
    5 years ago

    Hi Emmanuel,

    Thank you very much for writing such a detailed description!

    We really like your idea of templating the .env file. We even have done a first step of that in the op inject command already: allowing variables in the reference, so you can use the same configuration for multiple different environments. You can find it described here: https://developer.1password.com/docs/cli/guides/config-files#step-4-differentiate-between-environments . We're planning on adding the same variable support to op run for environment files as well. How do you feel about that?

    Regarding your use case of having a default configuration that's overloaded with values specific to a single environment, would a setup with multiple environment files, e.g. defaults.env and production.env work for you? When you pass multiple environment files to op run, variables defined in the second file take precedence over variables defined in the first file.


    op run --dotenv-file defaults.env --dotenv-file production.env -- ./run-your-app

    Would love to hear your thoughts and iterate on this further! Thank you so much for all your feedback so far! ❤️

    Cheers,
    Simon