|
| 1 | +## Installation of Bundles containing Webhooks |
| 2 | + |
| 3 | +!!! note |
| 4 | +This feature is still in *alpha*. Either the `WebhookProviderCertManager`, or the `WebhookProviderOpenshiftServiceCA`, feature-gate |
| 5 | +must be enabled to make use of it. See the instructions below on how to enable the feature-gate. |
| 6 | + |
| 7 | +OLMv1 currently does not support the installation of bundles containing webhooks. The webhook support feature enables this capability. |
| 8 | +Webhooks, or more concretely Admission Webhooks, are part of Kuberntes' [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) |
| 9 | +feature. Webhooks run as services called by the kube-apiservice in due course of processing a resource related request. They can be used to validate resources, ensure reasonable default values, |
| 10 | +are set, or aid in the migration to new CustomResourceDefinition schema. The communication with the webhook service is secured by TLS. In OLMv1, the TLS certificate is managed by a |
| 11 | +certificate provider. Currently, two certificate providers are supported: CertManager and Openshift-ServiceCA. The certificate provider to use given by the feature-gate: |
| 12 | + |
| 13 | +- `WebhookProviderCertManager` for [CertManager](https://cert-manager.io/) |
| 14 | +- `WebhookProviderOpenshiftServiceCA` for [Openshift-ServiceCA](https://github.com/openshift/service-ca-operator) |
| 15 | + |
| 16 | +As CertManager is already installed with OLMv1, we suggest using `WebhookProviderCertManager`. |
| 17 | + |
| 18 | +### Update OLM to enable Feature |
| 19 | + |
| 20 | +```terminal title=Enable WebhookProviderCertManager feature |
| 21 | +kubectl kustomize config/overlays/featuregate/webhook-provider-certmanager | kubectl apply -f - |
| 22 | +``` |
| 23 | + |
| 24 | +Or, |
| 25 | + |
| 26 | +```terminal title=Enable WebhookProviderOpenshiftServiceCA feature |
| 27 | +kubectl kustomize config/overlays/featuregate/webhook-provider-openshift-serviceca | kubectl apply -f - |
| 28 | +``` |
| 29 | + |
| 30 | +Then, |
| 31 | + |
| 32 | +```terminal title=Wait for rollout to complete |
| 33 | +kubectl rollout status -n olmv1-system deployment/operator-controller-controller-manager |
| 34 | +``` |
| 35 | + |
| 36 | +### Notes on the generated certificate |
| 37 | + |
| 38 | +#### CertManager |
| 39 | + |
| 40 | +The generated certificate maintains a high-level of parity with the certificate generated by OLMv0: |
| 41 | +- Self-signed |
| 42 | +- Two validity period, rotating 24h before expiry |
| 43 | +- Valid for the webhook service's DNSNames: |
| 44 | + - <service-name>.<namespace> |
| 45 | + - <service-name>.<namespace>.svc |
| 46 | + - <service-name>.<namespace>.svc.cluster.local |
| 47 | + |
| 48 | +#### Openshift-ServiceCA |
| 49 | + |
| 50 | +Generation and rotation are completely governed by [Openshift-ServiceCA](https://github.com/openshift/service-ca-operator) |
| 51 | + |
| 52 | +### How does it work? |
| 53 | + |
| 54 | +There's no change in the installation flow. Just install a bundle containing webhooks as you would any other. |
| 55 | + |
| 56 | +### Demo |
| 57 | + |
| 58 | +!!! note |
| 59 | +As there is no difference in usage or experience between the CertManager and Openshift-ServiceCA variants, only |
| 60 | +the cert-manager variant is demoed. |
| 61 | + |
| 62 | +[](https://asciinema.org/a/GyjsB129GkUadeuxFhNuG4FcS) |
0 commit comments