Skip to content

Verifying Settings

Jeff Felchner edited this page Jan 14, 2018 · 3 revisions

When you have settings for your application, especially if that application is large-ish and especially if that application's down time costs a significant amount of money, you may want to put extra safeguards in place to make sure that settings don't get changed inadvertently.

Chamber can help you with that.

Note: It is worth mentioning that as this feature currently stands, it is designed for auditing and not for security. I welcome suggestions to improve this feature.

Getting Started

If you'd like to start verifying your settings, the first thing you need to do is to generate a signature keypair. Chamber looks for a specific keyname to do its settings verification work: .chamber.signature.pem

To generate this file, run:

chamber init --signature

This will generate files similar to what you've already seen before:

  • .chamber.signature.pem
  • .chamber.signature.enc
  • .chamber.signature.enc.pass
  • .chamber.signature.pub.pem

As always, the .pub.pem file gets checked in and the .pass file contains the encrypted private key's passphrase.

The verification private key should be much more closely guarded than the other private keys which may have been generated by chamber init. The verification key is used only to mark settings as "approved". It it never required to run the app.

Ideally you would want one person to have this key and who is responsible for reviewing settings changes.

Signing Settings for Approval

Once you have your keys, the Approver can review settings and decide whether the settings changes make sense. If they do, then you can sign them.

chamber sign

What this does is use .chamber.signature.pem to create some files alongside your YAML files. For those who've read about verifying ownership you'll be familiar with the fact that this creates a signature for each file.

Each signature file will look something like this:

Signed By:  Jeff Felchner
Signed Via: .chamber.signature.pem
Signed At:  2017-01-01 00:00:00 UTC

-----BEGIN CHAMBER SIGNATURE-----
H8MxaNAhRfbmvmkmANwDG3rHyrbvS1trIhCxFRNmCjMnf6VA35aFNuxdsCgEukTr
WPILQPJlRG0JKUKZ2Bq8DULNV5dmfHKy55D0PL24Tg/NTg9Y0KFtT1zhwrSlSOjV
zlObDrDC+NU22+8z+V2vhEcCZOn55QdUlM1q8UCpIkO/qBU1Gk2IW+PTc+aXfbTO
k52n/MN51uzb3e3tQFFfFLXXqlCJ+sFlQfs9lH2Ft7TH69FpyamXJX8R7O5eI/Sw
MfEjQxqV5IJ/jda45L+fWuqugJyQmkqjiUSF6iQkmtHb01cYAqWn3hf97u1EmR0H
eiBVlcCUVybI335KVAx50A==
-----END CHAMBER SIGNATURE-----

and the files themselves will be named after the original YAML file. For example, if the YAML file is called settings-development.yml, then the signature file would be named settings-development.sig. The signature files live alongside the corresponding YAML file.

Note: If Chamber finds any .sig files, it will assume a missing signature file for a YAML file to be an error.

Note: ALL of the signature files should be checked in and committed to version control.

Verifying Settings

Now that the signature files are all committed to version control, the settings can be verified at any time by running:

chamber sign --verify

This command is designed as a good Unix utility and will output nothing in the successful case. However, if there's an issue, it will output the misbehaving files to STDERR (and exit with an error code).

Note: Because the signature public key is checked into version control, anyone who pulls down the repository can verify the settings, even if they don't have any other Chamber key installed.

Automating Verification

Boot Time

If signature files are found, and you're building a project which is supported by one of our official project plugins, Chamber will run a verification during boot time for any non-production environment.

If the verification fails, a warning will be sent to the console.

Commit Time

Any time a commit is made which changes settings, a Chamber hook built into overcommit will output a helpful warning to let you know that your settings need to be approved. Just make sure you have:

ChamberVerification:
  enabled: true

in your PreCommit section of your .overcommit.yml file and everything will work.

Clone this wiki locally