mirror of
https://github.com/getsops/sops.git
synced 2026-02-05 12:45:21 +01:00
82 lines
3.1 KiB
ReStructuredText
82 lines
3.1 KiB
ReStructuredText
All-in-one example
|
|
==================
|
|
This directory is an example configuration for SOPS inside of a project. We will cover the files used and relevant scripts for developers.
|
|
|
|
This example is optimized for saving developer time by storing all secrets in a single file (e.g. ``secret.enc.json``).
|
|
|
|
One downside is any configurations which should be stored side by side might not be.
|
|
|
|
Getting started
|
|
---------------
|
|
To use this example, run the following:
|
|
|
|
.. code:: bash
|
|
|
|
# From the `sops` root directory
|
|
# Import the test key
|
|
gpg --import tests/sops_functional_tests_key.asc
|
|
|
|
# Navigate to our example directory
|
|
cd examples/all_in_one
|
|
|
|
# Decrypt our secrets
|
|
bin/decrypt-config.sh
|
|
|
|
# Optionally edit a secret
|
|
# bin/edit-secret.sh config/secret.enc.json
|
|
|
|
# Run a script that uses our decrypted secrets
|
|
python main.py
|
|
|
|
Storage
|
|
-------
|
|
In both development and production, we will be storing the secrets file unencrypted on disk. This is for a few reasons:
|
|
|
|
- Can't store file in an encrypted manner because we would need to know the secret to decode it
|
|
- Loading it into memory at boot is impractical
|
|
|
|
- Requires reimplementing SOPS' decryption logic to multiple languages which increases chance of human error which is bad for security
|
|
- If someone uses an automatic process reloader during development, then it could get expensive with AWS
|
|
|
|
- We could cache the results from AWS but those secrets would wind up being stored on disk
|
|
|
|
As peace of mind, think about this:
|
|
|
|
- Unencrypted on disk is fine because if the attacker ever gains access to the server, then they can run ``sops --decrypt`` as well.
|
|
|
|
Files
|
|
-----
|
|
- ``bin/decrypt-config.sh`` - Script to decrypt secret file
|
|
- ``bin/edit-config-file.sh`` - Script to edit a secret file and then decrypt it
|
|
- ``config/secret.enc.json`` - Catch-all file containing our secrets
|
|
- ``config/secret.json`` - Decrypted catch-all secrets file
|
|
- ``config/static.py`` - Configuration file which imports secrets
|
|
- ``.gitignore`` - Ignore file for decrypted secret file
|
|
- ``main.py`` - Example script
|
|
|
|
Usage
|
|
-----
|
|
Development
|
|
~~~~~~~~~~~
|
|
For development, each developer must have access to the PGP/KMS keys. This means:
|
|
|
|
- If we are using PGP, then each developer must have the private key installed on their local machine
|
|
- If we are using KMS, then each developer must have AWS access to the appropriate key
|
|
|
|
Testing
|
|
~~~~~~~
|
|
For testing in a public CI, we can copy ``secret.enc.json`` to ``secret.json``. This will represent the same structure as ``secret.enc.json`` with an additional ``sops`` key but not reveal any secret information.
|
|
|
|
..
|
|
|
|
For convenience, we can run ``CONFIG_COPY_ONLY=TRUE bin/decrypt-config.sh`` which will use ``cp`` rather than ``sops --decrypt``.
|
|
|
|
For testing in a private CI where we need private information, see the `Production instructions <#production>`_.
|
|
|
|
Production
|
|
~~~~~~~~~~
|
|
For production, we have a few options:
|
|
|
|
- Build an archive (e.g. ``.tar.gz``) in a private CI which contains the secrets and deploy our service via the archive
|
|
- Install PGP private key/KMS credentials on production machine, decrypt secrets during deployment process on production machine
|