Handling of sensitive informations

[blackhatcrazy]

Feature request

Is your feature request related to a problem?

Currently the file generation capabilities of coco are limited to non-sensitive
data. This is due to the 2 constraints:

• there is no mechanism to fetch sensitive data from a third-party system (e.g.
  a credential store or a cloud provider)
• there is no mechanism to encrypt sensitive data for safe storage

This becomes e.g. problematic when dealing with kubernetes secrets which are
only base64 encoded. 2 common solution for storing these files securely are
sealed-secrets and
sops, which create encrypted versions of the
relevant parts of these secrets.

When sensitive information is encrypted, a mechanism to accurately label the
information for lifecycle management purposes must also be present which does
not require decrypting the information.

Describe the solution you'd like

I would like to have a coco secret command that allows for the lifecycle
management of sensitive data, in particular the following sub-commands should be
available:

• create
  • force (bool): forces the creation, even if a secret already exists
• delete
  • force (bool): forces the deletion, even if checks would prevent this
    (reasonible check could be if the secret is currently used in cluster)
• list
  • contains: ([]string) only secrets whose path contains all specified values
    will be listed
  • create-after: (timestamp) only secrets created after this timestamp will
    be listed
  • create-before: (timestamp) only secrets created before this timestamp will
    be listed
  • filter: (map[string]string) only secrets that contain all key-value
    label-pairs will be listed

For creation and deletion of sensitive data, coco needs to connect to external
systems with unique api-endpoints. Therefore, the communication with an external
system should be handled via plugins that can be referenced in the control
surface for each secret. Communication between plugins and coco must be
standardised to a well defined interface.

general structure

CoCo secret takes a file as control inputs that holds all metadata required for
managing 1 sensitive information (the inputs are detailed out in section
control-input).

• CoCo uses this file to identify a suitable plugin that will perform the
  communication with the external system.
• In addition, non-sensitive inputs to the plugin are provided in this file, see
  plugin-interface for details on the expected
  communication interface.
• CoCo internally hands off to the plugin, providing all input parameters.
• After receiving a reply from the plugin, CoCo processes the reply for
  fulfilling the user command.

control inputs

Each secret that should be managed by coco is identified by a configuration
yaml-file that should have control-inputs compatible with
ExternalSecrets.
Roughly speaking, this means the file specifies

• secret name
• namespace
• annotations
• labels
• mappings from source-file structure to the data-section of a kubernetes
  secret.

Additionally, the following annotations are required for coco:

coco.secret.creationTime: (timestamp) marks the creationtime and is set by coco
coco.secret.input.<key>: (string) <value>
coco.secret.plugin:
  (string) plugin identifier (available plugin name for internally implemented
  plugins, path relative to <basepath> for external script plugins)
coco.target.file: relative filepath where the SealedSecret will be saved

plugin interface

The communication between CoCo and script-plugins must abide by the following
interface:

Every plugin supports the following commands:

• create
• delete
• show

Every plugin accepts commandline flags of the form --flagName flagValue for
non-sensitive information. Every plugin is expected to return a status code (0
for success) and a json file with content:

{
  "debug": "(string) description for debugging purposes [optional]",
  "error": "(string) error message [only required if status code is not 0]",
  "result": "(string) response from the source system holding the new sensitive data"
}

create logic

• read the configuration file for the secret that shall be created
• hand off to the relevant plugin for secret creation
• parse the sensitive information from the plugins reply
• create a SealedSecret from the sensitive information using the additional
  inputs from the configuration file

delete logic

• read the configuration file for the secret that shall be created
• hand off to the relevant plugin for secret deletion
• parse the reply for errors

list logic

• find all secret configuration files that are selected by the various filters
• return the found file names