sops/examples/all_in_one
Felix Fontein 2ae16f5457 Add and use encrypt and decrypt subcommands.
Signed-off-by: Felix Fontein <felix@fontein.de>
2024-02-06 15:00:33 +01:00
..
bin Add and use encrypt and decrypt subcommands. 2024-02-06 15:00:33 +01:00
config Update sops format version for example files 2019-12-10 14:47:45 -08:00
.gitignore Added all-in-one example 2016-02-24 22:02:22 -06:00
README.rst Add and use encrypt and decrypt subcommands. 2024-02-06 15:00:33 +01:00
main.py Added all-in-one example 2016-02-24 22:02:22 -06:00

README.rst

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