1Password Business makes it easy to monitor events that happen on your team using the Activity Log, and you can take that to the next level by adding Splunk to the mix. Using the 1Password command-line tool, you can send your team’s 1Password activity to Splunk and keep track of it there alongside other happenings within your team.
One of Splunk’s most popular features is the ability to find events and trigger alerts based on them. For example, in your team you could set things up so the sysadmins are alerted whenever someone is added to the Owners group in 1Password. I’ll get into that example a bit more later in this post.
Set up the 1Password command-line tool
To kick things off, let’s set up the 1Password command-line tool, if you’re not using it already:
When setting up the tool, start by creating a custom group and giving it the View Admin Console permission so it can view the Activity Log, then add a user to that group. Once the tool is set up with that user’s account, get a session token:
$ op signin example
This will allow you to interactively enter the Master Password with secure input. Since you’re definitely putting this in a script, you’ll want to pass the Master Password through
stdin to the
op signin call to get your session token:
[password] | op signin example.1password.com firstname.lastname@example.org A3-XXXXXX-XXXXXX-XXXXX-XXXXX-XXXXX-XXXXX
To make things simpler, you can omit the email address and Secret Key from
op signin since they are saved in
~/.op/config. You can then simplify the whole sign in step to one line by piping the Master Password to it:
gpg -q --decrypt password.enc | op signin example
To automate all this, though, you can get the Master Password from a secure storage location and pipe it to sign in. A HashiCorp vault is a good place to securely store the account’s Master Password. I’m using GPG in this example, but you can use KMS or something else that you’re comfortable with – just avoid
Start fetchin’ those audit events
Now that we have our session token, we can start getting some audit events. Create a script that’s run by a job scheduler such as cron at regular intervals (every 10 minutes should suffice). That script needs to:
- Create the session like we just did above.
- Read the last processed event ID from disk.
- Fetch events newer than that ID.
- Send the events to Splunk.
- Save the latest event ID to disk.
To do this, we’ll be working with JSON, so JQ is a good idea if you’re working with bash; you could also use a scripting language that supports JSON, such as Python or Ruby.
You can fetch up to 100 events newer than $ID. To fetch them:
op list events $ID newer
To make sure you get all the events, you’ll need to run that until nothing is returned, since only 100 events are returned each time. This command will return a JSON array of event objects like this:
You can send all of the events in the array to Splunk at this point by using something like the Splunk universal forwarder.
Next, take the
eid of the first object in that array and save it to disk so it can be used for the next fetch. If the array from
op list events is empty, it means there are no newer events, and you’re done here — for now.
Get alerts about important actions in your team
Earlier I mentioned one such handy use for Splunk with 1Password Business would be to see when someone is added to the Owners group. To do this, you would find an event in the Activity Log that has:
- objectUuid: your Owners group’s UUID, which you can get by opening https://start.1password.com/groups, signing in, and clicking Owners, then copying the UUID from the end of the address bar in your browser.
Every audit event comes with a
actorUuid field. It’s a great identifier, but when perusing, we have no idea who
YJTZ3RWWFRBNTF4M2YEEY3EPOQ is. To fix this up, let’s upgrade our script a bit. Before we fetch events, let’s get a user list with
op list users. This will get us all users on the account along with some basic information like their name and email address. With that we can process each event object, look up the user by UUID, then add more descriptive information for when we send things to Splunk.
In this example case of sending an alert when someone is added to the Owners group, it’s probably nice to know who was added. The
auxUUID field of the audit event will be the UUID of the user who was added to the group. You can do the same lookup that we did above for the actor. For many events,
auxUUID will not be a user UUID, so make sure to fail gracefully there.
Now that we’ve set things up, whenever Splunk finds an event matching this, it’ll be able to alert your sysadmins via Slack or another method and let them know that Lorraine added Bobby to the Owners group. From there, they can take action if they need to.
Try it out and tell us what you think
When it comes down to it, sending your team’s 1Password activity to Splunk gives you one place to audit any administrative action your team has been taking in 1Password, alongside all the other tools your company uses. There are a lot of things you can look out for, from the Owners group example I mentioned before to knowing when someone adds or removes a team member from a vault or changes their permissions.
We’d love to hear how you set things up, so feel free to comment below or send us a message at email@example.com or start a discussion in our forum with suggestions, questions, and anything else you’d like to chat about!