diff --git a/INSTALL.md b/INSTALL.md index 598bdeee9..8e9ab53d0 100644 --- a/INSTALL.md +++ b/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 \ + --from-file=ca.crt= +``` + +You can then specify the `` 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): diff --git a/api/repositories/image_repository_test.go b/api/repositories/image_repository_test.go index 25cff20f6..88e66c82a 100644 --- a/api/repositories/image_repository_test.go +++ b/api/repositories/image_repository_test.go @@ -156,7 +156,6 @@ var _ = Describe("ImageRepository", func() { userClientFactory, rootNamespace, "", - registryCAPath, imageBuilder, imagePusher, ) diff --git a/docs/using-container-registry-signed-by-custom-ca.md b/docs/using-container-registry-signed-by-custom-ca.md deleted file mode 100644 index c728205c9..000000000 --- a/docs/using-container-registry-signed-by-custom-ca.md +++ /dev/null @@ -1,16 +0,0 @@ -# Use container registry signed by custom CAs -Korifi can be configured to use a custom registry that has a self-signed certicate. -Korifi accepts the `REGISTRY_CA_FILE` environment variable to point to a mounted secret containing the registry's CA cert. - -## Configure korifi-api - -- Create a secret containing the registry's CA cert in the `korifi-api-system` namespace. (see instructions) - For example: `kubectl -n korifi-api-system create secret generic registry-ca-cert --from-file=cacerts.pem=./ca-cert.pem` -- Update [deployment definition](https://github.com/cloudfoundry/korifi/blob/main/api/config/base/deployment.yaml) to mount the secret (see [instructions](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)) -- Set `REGISTRY_CA_FILE` environment variable on the deployment to point to the path of the mounted ca.crt file. - -## Configure kpack-image-builder -Use the same instructions as above, but create secret in the `korifi-kpack-build-system` namespace and use this [deployment definition](https://github.com/cloudfoundry/korifi/blob/main/kpack-image-builder/config/manager/manager.yaml) - -## Kpack -Kpack does not support self-signed/internal CA configuration out of the box [see: pivotal/kpack#207](https://github.com/pivotal/kpack/issues/207) and providing support for that is not something in scope for us to take on. 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. \ No newline at end of file