Project: external-secrets (Provisioning / Security & Compliance)
File: 004-datafrom-key-rewrite.md

```yaml title: dataFrom key rewrite version: v1alpha1 authors: creation-date: 2022-05-25 status: draft ``` <!-- toc --> // autogen please <!-- /toc --> DataFrom key rewrite aims to give users the possibility to rewrite secret keys before manipulating into a template. This feature is specially useful with the addition of `dataFrom.find` introduced in v0.5.0, as a way to allow users to rewrite secret keys in batches, without knowing the full content of the key. It is hard to administer key creation without having weird names that convolutes with the path. It is natural to have a feature to allow secret Keys manipulation both from the lifecycle of the secret management and as part of the templating feature. CRD Design for dataFrom key rewrite Do not implement secret values rewrite - this should be done with templating - nor handle initial secret value conversion (see ). Secret Key: the kubernetes secret key, aka the `string` in `mapbyte` in the codebase used to render Kubernetes Secrets. Add a rewrite step after applying either `GetSecretMap` or `GetAllSecrets`, but before applying any conversion logic. This allows us to apply individual mappings to different `dataFrom` groups so they can be composed well together in combination with `data` (see example below). As an user I want to be able to remove paths from my Secret Keys As an user I want to be able to customize secret keys to have more meaningful value to the tenants consuming it. As an user I want external-secrets to tell me if there is any rewrite conflict and not to overwrite secrets information. Proposed CRD changes: ```yaml apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: sample namespace: default spec: refreshInterval: 1m target: name: foobar secretStoreRef: name: secretstore-sample kind: SecretStore dataFrom: extract: key: /foo/bar rewrite: regexp: source: my-known-key target: newkeyname regexp: source: my-unknown-(.*) target: unknown-$1 find: conversionStrategy: Unicode path: "my/path/" name: regexp: "my-pattern" rewrite: regexp: source: my/path/(.*) target: $1 regexp: source:

target: $2-$1 find: conversionStrategy: Default path: "my/path/" tags: env: dev rewrite: regexp: source: my/path/(.*) target: dev-$1 ``` After applying `GetAllSecrets` or `GetSecretMap`, a rewrite logic is applied by using regular expressions capture groups. This will convert the Secret Keys according to a given standard, possibly even up to a well known key for the `GetSecretMap`. After the key rewrite is done, the `ConversionStrategy` should be applied, and then the new collection of Secret Keys (`mapbyte`) can be rendered to template. adding a prefix/suffix - will transform `my-secret` in `my-preffix-my-secret-my-suffix` ``` rewrite: regexp: source: (.*) target: my-preffix-$1-my-suffix ``` removing a prefix/suffix - will transform `my-preffix-my-secret-my-suffix` into `my-secret` ``` rewrite: regexp: source: my-preffix-(.*)-my-suffix target: $1 ``` Replacing characters - will transform `my/path/reader_db.creds-webapp` into `my-path-reader-db-creds-webapp` ``` rewrite: regexp: source: \.|-|_|/ #standardizing separation with '-' target: - ``` Removing path from the key name - will transform `my/path/reader-db-creds-webapp` into `reader-db-creds-webapp` ``` find: conversionStrategy: Default path: "my/path/" tags: env: dev rewrite: regexp: source: my/path/(.*) target: $1 ``` Combining operations - will transform `my/path/reader-db-creds-webapp` into `db-creds-reader` ``` find: conversionStrategy: Default path: "my/path/" tags: env: dev rewrite: regexp: source: my/path/(?P<secret>.*) target: $secret regexp: source: (?U)(?P<role>.)-(?P<app>.)-webapp target: $app-$role ``` It would not be trivial to replace a specific set of existing characters for new characters with this strategy. This could be implemented with a `replace` method afterwards. There are also some known limitations to golang regexp library, which implementes RE2. Some of the known limitations include: Lack of ability to do lookaheads or lookbehinds Lack of negation expressions Lack of support to conditionl branches. Lack of support to possessive repetitions. A list of compatibility and known limitations considering other commonly used regexp frameworks (such as PCRE and PERL) are listed here https://github.com/google/re2/wiki/Syntax If multiple keys have the same name an error should happen to the user referencing the original Secret Keys. A rewrite respects the regular expression limits A rewrite is compatible with `dataFrom.extract` and `dataFrom.find` It should be possible to remove paths with the `rewrite` operation. Add provider-specific ConversionStrategies, which would be painfully hard to maintain.