make tls pr798 use additionalVolumes capability from pr736 (#920)

* make tls pr798 use additionalVolumes capability from pr736

* move the volume* sections lower

* update helm chart crds and docs

* fix user.md typos

docs/reference/cluster_manifest.md

@@ -435,5 +435,12 @@ Those parameters are grouped under the `tls` top-level key.
   client connects with `sslmode=verify-ca` or `sslmode=verify-full`.
   Default is empty.
 
+* **caSecretName**
+  By setting the `caSecretName` value, the ca certificate file defined by the
+  `caFile` will be fetched from this secret instead of `secretName` above.
+  This secret has to hold a file with that name in its root.
+
   Optionally one can provide full path for any of them. By default it is
   relative to the "/tls/", which is mount path of the tls secret.
+  If `caSecretName` is defined, the ca.crt path is relative to "/tlsca/",
+  otherwise to the same "/tls/".

docs/user.md

@@ -585,7 +585,7 @@ OpenShift allocates the users and groups dynamically (based on scc), and their
 range is different in every namespace. Due to this dynamic behaviour, it's not
 trivial to know at deploy time the uid/gid of the user in the cluster.
 Therefore, instead of using a global `spilo_fsgroup` setting, use the `spiloFSGroup` field
-per Postgres cluster.```
+per Postgres cluster.
 
 Upload the cert as a kubernetes secret:
 ```sh
@@ -594,7 +594,7 @@ kubectl create secret tls pg-tls \
   --cert pg-tls.crt
 ```
 
-Or with a CA:
+When doing client auth, CA can come optionally from the same secret:
 ```sh
 kubectl create secret generic pg-tls \
   --from-file=tls.crt=server.crt \
@@ -602,9 +602,6 @@ kubectl create secret generic pg-tls \
   --from-file=ca.crt=ca.crt
 ```
 
-Alternatively it is also possible to use
-[cert-manager](https://cert-manager.io/docs/) to generate these secrets.
-
 Then configure the postgres resource with the TLS secret:
 
 ```yaml
@@ -619,5 +616,29 @@ spec:
     caFile: "ca.crt" # add this if the secret is configured with a CA
 ```
 
+Optionally, the CA can be provided by a different secret:
+```sh
+kubectl create secret generic pg-tls-ca \
+  --from-file=ca.crt=ca.crt
+```
+
+Then configure the postgres resource with the TLS secret:
+
+```yaml
+apiVersion: "acid.zalan.do/v1"
+kind: postgresql
+
+metadata:
+  name: acid-test-cluster
+spec:
+  tls:
+    secretName: "pg-tls"    # this should hold tls.key and tls.crt
+    caSecretName: "pg-tls-ca" # this should hold ca.crt
+    caFile: "ca.crt" # add this if the secret is configured with a CA
+```
+
+Alternatively, it is also possible to use
+[cert-manager](https://cert-manager.io/docs/) to generate these secrets.
+
 Certificate rotation is handled in the spilo image which checks every 5
 minutes if the certificates have changed and reloads postgres accordingly.