add a new SecretClaim resource?

this kinda came up in various discussions https://github.com/redhat-developer/opencompose/issues/138#issuecomment-303726800 https://github.com/redhat-developer/opencompose/pull/149#issuecomment-306184475 https://github.com/redhat-developer/opencompose/issues/47#issuecomment-305821903 and is kinda a follow on from the App idea proposal: https://github.com/redhat-developer/opencompose/issues/138#issuecomment-303726800

what if we added a secrets property which was a list of SecretClaimSpec resources which looked something like this:

// represents an apps claim for a Secret without including the actual Secret
// similar to PersistentVolumeClaim and PersistentVolume
// which tools can use to generate default Secrets
type SecretClaimSpec struct {
  Name string
  Kind string // has possible values 'userPassword', 'sshKeyPair', 'gpg', ...
  // parameters used to help generate the OpenShift Template parameters etc.
  Parameters  map[string]ParameterSpec
}

Then we don't include real secrets in source code or git; we just include the claim for secrets.

We give the metadata for what kind of secret is required so that we can use this metadata to generate a Secret inside the OpenShift Template or Helm Chart which uses parameterized values for things like user name / password or SSH key pairs, GPG keys or whatever. We can either let the values be totally generated randomly (nice and secure!) or provide simple but massively insecure developer defaults (admin/admin ;) (which we should warn user from using on any real cluster!). e.g. like we do in the fabric8 project: https://github.com/fabric8io/fabric8/blob/master/docs/secretAnnotations.md

Then users have the choice to exclude all the Secrets for the generated OpenShift Template or whether to use a Template which has parameterized Secrets via OpenShift Templates / Helm Charts.

Or maybe we always include the SecretClaims (either as a ThirdPartyResource / new upstream kubernetes / API Group or hack it as a ConfigMap ;) in the generated Kubernetes YAML resource and decouple the actual generation of the Secrets from the SecretClaims - which could be a microservice which runs in each environment and is configured to use random, OOTB defaults or import secrets from some tool like Vault or git - or the Secrets could just be manually created by operators using any tool of their choosing and we have tooling to check that the SecretClaims match up to the Secrets?

redhat-developer / opencompose

add a new SecretClaim resource? #161