---
tags: Discussion
---
# Airshipctl Secrets Generate

## What to change :
- How do we remove the document_path from the catalogues. We should be able to use GKV to find the appropriate documents in the Document Bunddle.
- Discussed having an output path to identify where the documents generated can be placed.
- Idea would be we rely on endpoint + artifact name to find the appropriate artifact
- Gap here is what about new artifacts, will generate create them by defaulkt as a Kind:Secret??

- Encrypted should be the default value for the catalogues.
-
- No need for a command that encapsulates bith passphrases and certifictes into one. Its ok if we have two different subcommands.

- We need a command to handle externally produced objects
Need to introduce to the document sets, public certificates, or externally managed passphrases.
This command might generate the appropriate Kubernetes Document, i.e. Kind:Secret
- As an idea of how to separete decryption and replacement: it's possible to refer to [the upstream sops plugin](https://github.com/GoogleContainerTools/kpt-functions-catalog/tree/master/examples/sops). It can work as a kustomize plugin, here is an [example](https://github.com/aodinokov/noctl-airship-poc/blob/master/packages/test_fn_sops/manifests/base/kustomization.yaml). (Note: you can use upstream image `gcr.io/kpt-functions/sops` instead of `quay.io/aodinokov/sops:v0.0.2` in [sops.yaml](https://github.com/aodinokov/noctl-airship-poc/blob/master/packages/test_fn_sops/manifests/base/sops.yaml)). If we need to do replacements, the corresponding replacement configuration must be put into a separate replacement plugin configuration and to be put AFTER sops.yaml in the `transformers` section. [Here](https://github.com/aodinokov/noctl-airship-poc/blob/master/packages/test_fn_sops/run.sh#L7) is how to run kustomize 3.8.1 or higher to make this example work.

## Proposed changes (Matt), addressing the first point above:
1. Define a `generation_sources.path` in `metadata.yaml`
This will be a kustomize entrypoint where the generation catalogues live
- e.g., `path: airshipctl/manifests/site/test-site/generation-sources`
2. Define a `generated_secrets.path` in `metadata.yaml`
This will be where all generated Secrets go
- e.g., `path: airshipctl/manifests/site/test-site/generated-secrets`
3. Separate "replacement" from "generation". The generator doesn't need to
manage the replacement; rather, we can follow the existing pattern of
using a `<function>/replacements/secrets.yaml` config to replace secrets
from the generated `kind: Secret` into the needed resources. Said
differently: functions should be responsible for replacing generated
secrets into their resources.
4. Adjust the catalogue format as follows:

apiVersion: secrets.airshipit.org/v1alpha1
kind: secretGenerate
metadata:
  name: secret-catalog
data:
  passphrases:
    # This will generate a Secret named "helm-release-password" in:
    #     <generated_secrets.path>/
    - name: 'helm-release-password'
      # encrypted: true  # by default
      # "replacements" is removed from here, into <function>/replacements/

      # Also include an optional regex defining the secret's pattern

4. Integration of the secrets into a particular phase is as simple as
adding these two lines to each phase kustomization.yaml that needs them:

# kustomization.yaml for `workload` phase
resources:
  - ../../../../type/airship-core/target/workload
  - ../catalogues
  - ../generated-secrets # New line of config
transformers:
  - sops.yaml # New line of config, decrypt the generated Secrets first
  # Note: this line will exist already, and will pull in the new replacements
  - ../../../../type/airship-core/target/workload/replacements

Note: I only see value in the replacement-oriented generation (Secrets with `deploy-k8s: false`) - I don't see value in generating Secrets that you plan to deploy into the cluster. The reasons are that:
- You'd always need to patch it on top of a corresponding Secret from a function, and that's additional integration work for the end user in their `kustomization.yaml`.
- Using replacement rules accomplishes the same thing but in a declarative, reusable way that is defined in the consuming functions themselves.
- You don't have to worry about things like "what namespace should my `kind: Secret` resource go in", which is not covered by the design doc. Instead, the namespace would already be defined in the "replaced into" resource.