add a new SecretClaim resource?

[jstrachan]

this kinda came up in various discussions #138 (comment) #149 (comment) #47 (comment) and is kinda a follow on from the App idea proposal: #138 (comment)

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?

[kadel]

This might be interesting, it's something that we should definitely investigate deeper.

We need to get #113 in first. That we can experiment with this more.

If we decide to remove Secretes values in favor of this we still can.