sopstool

sopstool EOL

Please note, this project is no longer maintained. The sops program itself has added a number of features that make this project redundant, and usage of the tool has largely migrated to using AWS Secrets Manager or AWS Parameter Store. This project is archived, and will not be updated.

The additional install repositories (https) are also deprecated and will be removed in the future.

The last release of sopstool was 1.2.1.

Introduction

sopstool is a multi-file wrapper around sops. It uses the sops binary to encrypt and decrypt files, and piggybacks off the .sops.yaml configuration file.

sopstool provides functionality to manage multiple secret files at once, and even use as an entrypoint to decrypt at startup, for container images. Much of this behavior is inspired by the great blackbox project.

sopstool

1.0.0 Release and Breaking Changes

1.0.0 release of sopstool introduces M1 / darwin-arm64 support. We also want to match build artifacts produced by GoReleaser to what sops produces. Therefore, this version introduces a breaking change where we no longer produce artifacts like sopstool_linux.(deb|rpm|tar.gz) and sopstool_darwin.tar.gz. Instead, you'll see artifacts like sopstool_darwin_(arm64|amd64)_(deb|rpm|tar.gz) and sopstool_linux_(arm64|amd64)_(deb|rpm|tar.gz) in future releases.

Installation

Package Repositories

sopstool is available in the following repositories

homebrew via the Ibotta/public tap: brew install Ibotta/public/sopstool
asdf (and mise) via the sopstool plugin: asdf plugin add sopstool

Container Image

Images are tagged with the same version numbering as the releases, and latest always gets the latest release. Note that your image will need root CA certificates (typically installed with curl, or a ca-certificates package).

To use sopstool from container (avoiding doing binary installs):

docker run --rm -v $(pwd):/work -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_REGION -e AWS_SECURITY_TOKEN -e AWS_SESSION_TOKEN ghcr.io/ibotta/sopstool:latest $COMMAND

sopstool is the entrypoint, so any sopstool subcommand can be run.
/work is the default WORKDIR - this should be mounted to the root where .sops.yml is stored.
The commands need access to your AWS credentials session to authenticate KMS.

Or, use as a COPY source in your Dockerfile. sops and sopstool are in /usr/local/bin/:

COPY --from=ghcr.io/ibotta/sopstool:latest usr/local/bin/sops usr/local/bin/sopstool /usr/local/bin/

Packages or binaries from Releases

Check the Releases for the latest artifacts

Binaries (compressed as .tar.gz or .zip) (note, you will need sops installed manually)
RPM, Debian and APK packages

All artifacts have their sha256 checksums recorded in sopstool_checksums.txt, and SPDX SBOM artifacts are available.

Shell installer

The most direct install uses a shell script hosted in this repository. This script will install the latest sops (if the command does not exist) and sopstool to ./bin by default.

curl https://raw.githubusercontent.com/Ibotta/sopstool/main/install.sh | bash

Override the sops version with the -s argument
Override the sopstool version with the -t argument
Override the binary install location with the -b argument
- remember, you may need sudo or root access if you are installing to /usr/*

Example with overrides:

curl https://raw.githubusercontent.com/Ibotta/sopstool/main/install.sh | bash -s -- -b /usr/local/bin -s 3.0.0 -t 0.3.0

Installing sops manually

sopstool requires sops. You can use one of the following methods:

From one of the public repositories (it is available in most)
From the official releases

Installing the sops binary with our script installer

The install script above uses a separate script to download sops

curl https://raw.githubusercontent.com/Ibotta/sopstool/main/sopsinstall.sh | bash

Override the tag with the first shell argument (defaults to latest)
Override the binary install location with the -b flag (defaults to /.bin)

Download sops from our https mirror (deprecated)

Note this method is deprecated, and will be removed in the future. Use one of the other methods instead.

To avoid needing to find the 'latest' binary by hand or by script, use our https server to download the binary. The latest binary is uploaded automatically whenever sopstool is deployed. The file has the pattern sops_$OS_$ARCH, except for windows

OS: linux, darwin
- ARCH: amd64, arm64
- filenames: sops_$OS_$ARCH.tar.gz
OS: windows
- ARCH amd64 only
- filename: sops_windows.zip
Versions
- latest: https://oss-pkg.ibotta.com/sops/$filename
- specific tags: https://oss-pkg.ibotta.com/sops/$TAG/$filename

Installing sopstool manually

Following the lead of sops, we only build 64bit binaries.

Installing the sopstool binary using our script installer

The install script above uses a separate script to download sopstool

curl https://raw.githubusercontent.com/Ibotta/sopstool/main/sopstoolinstall.sh | bash

Override the tag with the first shell argument (defaults to latest)
Override the binary install location with the -b flag (defaults to /.bin)

Download sopstool from our https mirror (deprecated)

Note this method is deprecated, and will be removed in the future. Use one of the other methods instead.

To avoid needing to find the 'latest' binary by hand or by script, use our https server to download the binary. The latest binary is uploaded automatically whenever sopstool is deployed.

OS: linux, darwin
- ARCH: amd64, arm64
- filenames: sopstool_$OS_$ARCH.tar.gz
OS: windows
- ARCH: amd64, arm64
- filename: sopstool_windows_$ARCH.zip
Versions
- latest: https://oss-pkg.ibotta.com/sopstool/$filename
- specific tags: https://oss-pkg.ibotta.com/sopstool/$TAG/$filename

Additionally, all other release assets are also within this folder. This includes the checksums, packages, SBOMS, as well as installers:

https://oss-pkg.ibotta.com/sopstool/install.sh for the combined installer
https://oss-pkg.ibotta.com/sopstool/sopsinstall.sh for the sops installer
https://oss-pkg.ibotta.com/sopstool/sopstoolinstall.sh for the sopstool installer

Usage

This is a package that builds a single binary (per architecture) for wrapping sops with multi-file capabilities.

For more details, use the built-in documentation on commands:

sopstool -h

to get the shell completion helpers:

#!/usr/bin/env bash
sopstool completion

#!/usr/bin/env zsh
sopstool completion --sh zsh

Configuration

use a .sops.yaml file
- This will be at the root of your project. This file is used to both configure keys and hold the list of files managed.
- It needs to specify at least one KMS key accessible by your environment
```
creation_rules:
  - kms: arn:aws:kms:REGION:ACCOUNT:key/KEY_ID
```
- it can specify more complex cases of patterns vs keys too (see link)

How-To

Create a KMS Key.
Follow along the Configuration Steps, and place the .sops.yaml file at the root directory where your scripts will run.
- All files added to SOPS are relative, or in child directories to the .sops.yaml configuration file.
Create a file to encrypt(any extension other than .yaml if you wish to do the ENTIRE file), or create a yaml file with key: value pairs(and make sure it's extension is .yaml). Sops will encrypt the values, but not it's keys.
- You can read more about SOPS Here.
At this point, sopstool is ready, and you can now sopstool add filename. You'll notice it will create a filename.sops.extension. This is your newly encrypted file.
- When your files are properly encrypted, you can run sopstool clean to remove the original plain text secret files.
Now, you can interact via the command line in various ways.
- Editing an encrypted file - sopstool edit filename.sops.extension. You can also use your original filename too! sopstool edit filename.extension
- Listing all encrypted files - `sopstool list

Sopstool

Install / Use

README