Secure secret storage in cludod server

[tammersaleh]

Currently, operators include the AWS keys (server.targets.TARGET.aws.access_key_id and
server.targets.TARGET.aws.secret_access_key) as plaintext in the cludod.yaml config file. This isn't gonna fly for actual usage.

Idea: Secrets in pluggable backends

• It's best to make the secret storage backend pluggable from the start. AWS KMS, GCP KMS, Azure Key Vault, Hashicorp Vault, etc.

• The configuration would then look something like:

  ``` yaml
  server:
    targets:
      prod:
        aws:
          vault_path: /path/to/keys/in/vault
  ```
  

• How do those keys get into the backend? Do we require the admin to set them up correctly? Do we give them a cludod add keys command?

Idea: Lean on sops

Sops can be used as a library. If we used that, then keys would still be in the main config file, and the format won't have to change. Then we get all of the sops backends and functionality for free.

This would mean that every value in the config would be encrypted, meaning operators would need to have access to the master decryption key (or AWS access to KMS) in order to view basically anything in the file.

A possible fix to that issue is to split the config into two files: cludod.yaml and cludod-secrets.yaml, which would result in a lot of structural overlap.

Idea: Support ENV vars

If we assume everyone's gonna be on K8s, then there's an argument not to attempt to solve this, and instead expect operators to put the secrets in ENV vars (via Secret resources), and allow cludod to parse ${VAR_NAME} directives in the configuration file.

[tammersaleh]

@spkane @jmcshane I'd love to hear your thoughts on this potential feature.

[tammersaleh]

One benefit of putting the credentials themselves into a managed backend would be the ability for the server to regularly rotate them.