Closed turkenh closed 2 years ago
@muvaf the other case we discussed where a user might want to include a non-sensitive field but not want to drop it from the schema (e.g. endpoint
of a db) could actually be covered with this feature as well and we wouldn't need another configuration.
Something like:
func dbCustomConnectionDetails(attr map[string]interface{}) map[string][]byte {
if ep, ok := attr["endpoint"]; ok {
return map[string][]byte{ "endpoint": ep}
}
return nil
}
What problem are you facing?
Currently, all fields marked as sensitive in Terraform schema were added as a connection detail key and were hidden from the schema (i.e. dropped if in status, converted to
secretref
if in spec). We are using terraform field names as keys which would also be helpful in terms of documenting what a connection detail secret includes as keys.However, there could be some cases where it makes sense to build a custom key specific to resource. For example, if a managed Kubernetes cluster returns different parts of a kubeconfig as separate keys, it would be convenient to construct a kubeconfig using them and store with
kubeconfig
key.How could Terrajet help solve your problem?
We should expose a custom configuration which allows to define additional keys for connection details by getting a function similar to external name config, for example:
func CustomConnectionConstructor(attr map[string]interface{}) map[string][]byte