Secret management CLI

Overview

Secret management CLI will be used to manage our key vault backed secrets

Commands

CLI: secretman.exe [topic]

Topics

- Authenticate - we might not actually need a command for this, we can just go down the authenticate path if it's needed.

- Add ["secret"|"type"] [keyvault] 

- Expire [keyvault] [name]

- Rotate [keyvault] [name]

- View ["secret"|"type"] [keyvault] (name)

- Validate

Metadata

Management metadata (manifest)

Metadata in the manifest will vary per secret type and will be used to interact with external services for secret management. Additionally, secret relationships (parent-child) will be maintained in the manifest. Manifest metadata is manually modified for v1. Having a tool based system for creating arbitrary secret types and defining relationships, would be costly.

Example:

secrets: {[
  "my external secret": {
    description: "Sql connection string used for external customers to access helix drops"
    owner: "[email protected]"
    type: "azure-storage-connection-string",
    values: {
      accountname: "helixexternaldrops",
      resource: "HelixProdKV"
      permissions: "read"
    }
  },
  "my internal secret": {
    description: "Sql connection string used for .NET Core engineering to access helix drops"
    owner: "[email protected]"
    type: "azure-storage-connection-string",
    values: {
      accountname: "helixinternaldrops",
      resource: "HelixStagingKV"
      permissions: "read"
    }
  }
]}

Secret state metadata (Key vault)

There is some metadata that can't be in a local manifest because having multiple manifests would lead to a high maintenance cost. Ie, it would be costly to have to update last modified time in multiple manifests. What is the source of truth and how do you handle conflicts?

Metadata in the key vault will include

- Expiration date (datetime)
- Last modified by (string)