Document global.containerRegistryCACertSecret

INSTALL.md

@@ -39,10 +39,6 @@ export ADMIN_USERNAME="cf-admin"
 export BASE_DOMAIN="korifi.example.org"
 ```
 
-### Registries with Custom CA
-
-See [_Using container registry signed by custom CA_](docs/using-container-registry-signed-by-custom-ca.md).
-
 ### Free Dockerhub accounts
 
 DockerHub allows only one private repository per free account. In case the DockerHub account you configure Korifi with has the `private` [default repository privacy](https://hub.docker.com/settings/default-privacy) enabled, then Korifi would only be able to create a single repository and would get `UNAUTHORIZED: authentication required` error when trying to push to a subsequent repository. This could either cause build errors during `cf push`, or the Kpack cluster builder may never become ready. Therefore you should either set the default repository privacy to `public`, or upgrade your DockerHub subscription plan. As of today, the `Pro` subscription plan provides unlimited private repositories.
@@ -112,6 +108,29 @@ Make sure the value of `--docker-server` is a valid [URI authority](https://data
   - `--docker-username` should be `_json_key`;
   - `--docker-password` should be the JSON-formatted access token for a service account that has permission to manage images in GCR.
 
+### TLS certificates
+
+Self-signed TLS certificates are generated automatically by the installation if `global.generateIngressCertificates` has been set to `true`.
+
+If you want to generate certificates yourself, you should not set the `global.generateIngressCertificates` value, and instead provide your certificates to Korifi by creating two TLS secrets in `$KORIFI_NAMESPACE`:
+
+1. `korifi-api-ingress-cert`;
+1. `korifi-workloads-ingress-cert`.
+
+### Container registry Certificate Authority
+
+Korifi can be configured to use a custom Certificate Authority when contacting the container registry. To do so, first create a `Secret` containing the CA certificate:
+
+```sh
+kubectl --namespace "$KORIFI_NAMESPACE" create secret generic <registry-ca-secret-name> \
+    --from-file=ca.crt=</path/to/ca-certificate>
+```
+
+You can then specify the `<registry-ca-secret-name>` using the `global.containerRegistryCACertSecret`.
+
+> **Warning**
+> Kpack does not support self-signed/internal CA configuration out of the box (see [pivotal/kpack#207](https://github.com/pivotal/kpack/issues/207)). Operators can modify the Kpack deployment, using something like the [cert-injection-webhook](https://github.com/vmware-tanzu/cert-injection-webhook) on the Kpack pods, or bring their own build reconciler in these cases.
+
 ## Install Korifi
 
 Korifi is distributed as a [Helm chart](https://helm.sh). See [_Customizing the Chart Before Installing_](https://helm.sh/docs/intro/using_helm/#customizing-the-chart-before-installing) for details on how to specify values when installing a Helm chart.
@@ -142,15 +161,6 @@ If you are using an authentication proxy with your cluster to enable SSO, you mu
 
 ## Post-install Configuration
 
-### TLS certificates
-
-Self-signed TLS certificates are generated automatically by the installation if `global.generateIngressCertificates` has been set to `true`.
-
-If you want to generate certificates yourself, you should not set the `global.generateIngressCertificates` value, and instead provide your certificates to Korifi by creating two TLS secrets in `$KORIFI_NAMESPACE`:
-
-1. `korifi-api-ingress-cert`;
-1. `korifi-workloads-ingress-cert`.
-
 ### DNS
 
 Create DNS entries for the Korifi API and for the apps running on Korifi. They should match the Helm values used to [deploy Korifi](#deploy-korifi):

api/repositories/image_repository_test.go

@@ -156,7 +156,6 @@ var _ = Describe("ImageRepository", func() {
 					userClientFactory,
 					rootNamespace,
 					"",
-					registryCAPath,
 					imageBuilder,
 					imagePusher,
 				)