Forum Discussion

Backspaze's avatar
Backspaze
Dedicated Contributor
3 years ago

How to use service accounts and regular accounts in the same environment?

I noticed that you silently released Service Accounts little over a week ago in https://app-updates.agilebits.com/product_history/CLI2#v2180001 of 1Password CLI and naturally began testing it immediately (a blog post announcement would've been nice for this (eventually) useful feature).

My use case is to only use the Service Account for scheduled scripts that should run without any user interaction, but I want to still be able to use the CLI with my personal account on the same device at the same time. Based on my testing I quickly ran into an issue with this and I've not been able to find the solution for it in the https://developer.1password.com/docs/. I'm signed in to the desktop app with my Family Account and have had it connected to the CLI for years, and it's been working great. After following the instructions for setting up a Service Account, the CLI is always using the Service Account for all of the commands I execute.

I'll repeat the steps below for clarity.

  • I ran op user get --me and it listed my personal account.
  • I ran $Env:OP_SERVICE_ACCOUNT_TOKEN = "<your-service-account-token>" and then ran op user get --me and it listed the Service Account.
  • I ran some tests with a script I'm going to use the Service Account for and it worked as expected.
  • I then tried to run op item get "1Password University" which is an item stored in my private vault, which the Service Account doesn't have access too (going for the principle of least privilege) and got the error [ERROR] 2023/05/25 19:47:41 a vault query must be provided when this command is called by a service account. Please specify one either through the --vault flag or through piped input.
  • I tried using the flag --account to tell it to use my personal account for the command (op item get "1Password University" --account ABCDEFGHIJKLMNOPQRSTWXYZ) which generated the same error.
  • I tried op vault list with and without the account flag which generated the same result; a list of the vault that the Service Account has access to.

The only way I've found to get the op user get --me command to show that I'm using my personal account again is to first run $Env:OP_SERVICE_ACCOUNT_TOKEN = "" to set it to an empty string. This caused the CLI to require me to authenticate for the next command I ran, but it also means that the Service Account isn't authenticated or used anymore and any scheduled script which is using secret references will prompt me for authentication.

Am I missing something or is it simply not possible to use this according to my use case? Do I have to use a VM or something like that and set up 1Password CLI on that machine and run all scheduled scripts from that device?

1Password Version: 1Password for Windows 8.10.7 (81007011)
Extension Version: 2.11.1 21100100, on BETA channel
OS Version: Windows 10 22H2
Browser:_ Firefox 113.0.1 (64-bit)
Referrer: forum-search:https://1password.community/search?Search=using%20service%20accounts%20at%20the%20same%20time%20as%20a%20regular%20user

CLI

3 Replies

  • Backspaze's avatar
    Backspaze
    Dedicated Contributor
    3 years ago

    Hey @"Horia.Culea_1P", any update on my thoughts in the last paragraph in my previous reply?

  • Backspaze's avatar
    Backspaze
    Dedicated Contributor
    3 years ago

    Hey @"Horia.Culea_1P"

    Thanks for the clarification.

    I'm not quite sure about exactly how to perform the steps you mentioned, so I'm thinking out loud here.

    First, I'm guessing I can add $Env:OP_SERVICE_ACCOUNT_TOKEN = "<your-service-account-token>" at the start of my script(s) and then reset it at the end of the script(s) with $Env:OP_SERVICE_ACCOUNT_TOKEN = "". But that would mean that every script I use this with will have my Service Account token included, and if any script goes astray that means anyone with access to the script will have access to my Service Account and everything it has access to.

    Second, If I instead go with your example with an envvar with a different name, I'm guessing the set up is done by running the command like this $Env:OP_SERVICE_ACCOUNT_TOKEN_GLOBAL = "<your-service-account-token>" and then, at the beginning of my script(s) I'll have a command like $Env:OP_SERVICE_ACCOUNT_TOKEN = $Env:OP_SERVICE_ACCOUNT_TOKEN_GLOBAL and at the end of the script(s) I'll have $Env:OP_SERVICE_ACCOUNT_TOKEN = "". I tried this and it didn't work, so I'm probably using the wrong method...on to the...

    ...Third attempt after reading some more about environment variables in PowerShell. I ran PowerShell as admin and used the command [Environment]::SetEnvironmentVariable("OP_SERVICE_ACCOUNT_TOKEN_GLOBAL", "<your-service-account-token>", "User") to make the envvar available at user level. At the start of the script I then added $Env:OP_SERVICE_ACCOUNT_TOKEN = $Env:OP_SERVICE_ACCOUNT_TOKEN_GLOBAL and I also added op user get --me to see that it actually switches to the service account for the script session. When I open a new PowerShell window after this and run the script, it seems to work as intended. The Service Account remains logged in and authenticated for that session, but if I close the PowerShell window and open a new one, it returns to using my personal account. If I add $Env:OP_SERVICE_ACCOUNT_TOKEN = "" and op user get --me to the end of the script I can make it return to using my personal account within the same session.

    Was my third attempt above what you had in mind or is there a better way to do this? Also do you have any more comments regarding my thoughts in the first paragraph about having the Service Account token in plain text in the script?

  • Former Member's avatar
    Former Member
    3 years ago

    Hey Backspaze , thank you for reaching out to us!

    a blog post announcement would've been nice for this (eventually) useful feature

    Thank you for flagging this! A blogpost is indeed coming along with the official launch, for now this feature has only been silently released, as you mentioned too.

    or is it simply not possible to use this according to my use case?

    Indeed it is not possible to use a user account with a service account token in the environment. This is by design, as we intend the service accounts credentials to only exist within the scope of their usage. In your case, that would be on a script level.

    Alternatively, in case you require keeping the service account token exported globally, you could use an envvar with a different name (e.g. having the token exported as OP_SERVICE_ACCOUNT_TOKEN_GLOBAL) and move its value to OP_SERVICE_ACCOUNT_TOKEN at the beginning of the scripts that require a service account.

    Hope this helps, let us know if you have any further questions!

    Best,
    Horia