Proposal: Add ability to specify environment for secrets

[chrisjsimpson]

For example user story: As a user I can specify an environment name of my choosing whilst storing a secret, perhaps with a default. When accesing a secret, the default environment is used.

e.g. Interface

(base) (environment)$ ./amber --verbose encrypt 
error: The following required arguments were not provided:
    <ENVIRONMENT>
    <KEY>

USAGE:
    amber encrypt [OPTIONS] <ENVIRONMENT> <KEY> [VALUE]

For more information try --help
(base) (environment)$ ./amber --verbose encrypt staging API_KEY secret
[2022-01-01T22:16:45Z DEBUG amber] Cmd { opt: Opt { verbose: true, amber_yaml: None, unmasked: false }, sub: Encrypt { environment: "staging", key: "API_KEY", value: Some("secret") } }
[2022-01-01T22:16:45Z DEBUG amber::cli] Checking if file "amber.yaml" exists
[2022-01-01T22:16:45Z INFO  amber::config] New value matches old value, doing nothing
(base) (environment)$ 

Possible structure: (Note the additon of "environment")

---
file_format_version: 2
public_key: 7801a1206e8e339c396a990bdd758dcccce9d1e8846b3a08b8329d3925adf801
secrets:
  - name: API_KEY
    environment: staging
    sha256: 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
    cipher: 104b00746ab5a029ee6c693e33d6cee116163b695d5ed685e1e8428984f5105012e3741ec89d4e944c4f02209762f11f69f6eed17be7
  - name: API_KEY
    environment: production
    sha256: 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
    cipher: 104b00746ab5a029ee6c693e33d6cee116163b695d5ed685e1e8428984f5105012e3741ec89d4e944c4f02209762f11f69f6eed17be7

Motivations

• Secrets may change between environments (e.g. testing, staging etc )
• Whilst it is possible to achieve managing different environment secrets with amber (potentially by managing amber.yaml in a different repo per environment, this undermines the goal to track the changes in values over time.

Considerations

• To store envrionment name per secret not elsewhere
• Provide a default environment name, or none
• This would/could be a breaking change to the file format so may require a bump of FILE_FORMAT_VERSION

I've coded an intial attempt at this to demonstrate the idea and will push, though a complete implementation is missing since I'm new to Rust. I specifically got stuck at: https://github.com/fpco/amber/blob/65e6c6ec8ee0669df71b9b56e6e3ab924e0d3fc2/src/config.rs#L109 after altering SecretRaw structure to include environment.

I hope the code tempts someone or someone can point me in a better direction.

[snoyberg]

This seems to break the current interface, which I'm not in favor of. Additionally, from a security perspective, I think it's a bad idea to use the same private key for different environments. I'd recommend separate files per env instead.

[chrisjsimpson]

Separate files per env makes a lot of sense, how did I miss that!?

I hit the issue when working with GitHub CI environments and didn't have that obvious thought.

So potentially amber-testing.yaml , amber-staging.yaml etc would address this exactly.

If useful I'll PR some docs on this since it's possible I'm not the only one to miss this, and miss that amber does cater to ,this use case. Failing that, will just let this thread be evidence for anyone else having the same misunderstanding.

[snoyberg]

A doc PR would be great!

[chrisjsimpson]

Here's a demo repo doc demonstrating amber in combination with GitHub actions with different envionrments:

https://github.com/chrisjsimpson/amber-secrets-ci-example (I'll proof read asap) perhaps not all needed for docs

[snoyberg]

I like the docs, they look great.