Webhooks deployed and managed by the API Connect Operator

The API Connect Operator deploys and manages various Kubernetes API webhooks in the cluster to assist in management of its custom resources.

The webhooks included admission controllers and conversion webhooks.

Defaulting webhook

Purpose
The defaulting webhook is a type of Mutating Admission Webhook which runs against Custom Resources (CRs) at CREATE or UPDATE time to populate default values in the CR's spec.
Creation
Currently the defaulting webhook runtime is part of the API Connect Operator runtime, that is it exists within the API Connect Operator pod and container. When the operator boots, it creates MutatingWebhookConfiguration resources for each CRD (listed below). This MutatingWebhookConfiguration is a cluster-scope resource, but the configuration within will be specific to the namespace and operator instance which created it. If more than one instance of the API Connect Operator is deployed across a cluster (in different namespaces) there will be a set of webhook configurations for each API Connect Operator instance and namespace.

The name for the MutatingWebhookConfiguration resource for each CRD will take the following form:
```
<namespace>.<crd-name>.defaulter[.<component>].apiconnect.ibm.com
```
The following CustomResourceDefinitions utilize a defaulting webhook:
```
AnalyticsCluster
ApiconnectCluster
GatewayCluster
ManagementCluster
ManagementDBUpgrade
ManagementRestore
PortalCluster
```
Lifecycle
While the defaulting webhook runtime itself lives within the API Connect Operator pod, the MutatingWebhookConfiguration is a cluster-scope resource and is stand-alone. When it is created, an ownerReference is set on it that references the API Connect Operator's ClusterRole. Thus, the lifecycle of the MutatingWebhookConfiguration resources will be linked with the ClusterRole, which is linked with the installation of the operator itself.

When the operator is uninstalled, the MutatingWebhookConfiguration resources for that operator instance are also removed.

Example

The below output shows the defaulting webhook configurations created for an operator deployed in the apiconnect-operator namespace. One can be seen for each CRD.

$ oc get mutatingwebhookconfiguration
NAME                                                                               WEBHOOKS   AGE
apiconnect-operator.analyticsclusters.defaulter.analytics.apiconnect.ibm.com       1          4d4h
apiconnect-operator.apiconnectclusters.defaulter.apiconnect.ibm.com                1          4d4h
apiconnect-operator.gatewayclusters.defaulter.gateway.apiconnect.ibm.com           1          4d4h
apiconnect-operator.managementclusters.defaulter.management.apiconnect.ibm.com     1          4d4h
apiconnect-operator.managementdbupgrades.defaulter.management.apiconnect.ibm.com   1          4d4h
apiconnect-operator.managementrestores.defaulter.management.apiconnect.ibm.com     1          4d4h
apiconnect-operator.portalclusters.defaulter.portal.apiconnect.ibm.com             1          4d4h

Validating webhook

Purpose
The validating webhook is a type of ValidatingAdmissionWebhook which runs against Custom Resources (CRs) at CREATE or UPDATE time to validate the CR contains a configuration which will yield an operable cluster. The CustomResourceDefinitions use OpenAPI schema validation for basic property checks (such as integer bounds and non-empty strings), but more complex validation of the configuration is done via the webhook.
Creation
Currently the validating webhook runtime is part of the API Connect Operator runtime, i.e. it exists within the API Connect Operator pod and container. When the operator boots, it creates ValidatingWebhookConfiguration resources for each CRD (listed below). This ValidatingWebhookConfiguration is a cluster-scope resource, but the configuration within will be specific to the namespace and operator instance which created it. If more than one instance of the API Connect Operator is deployed across a cluster (in different namespaces) there will be a set of webhook configurations for each API Connect Operator instance and namespace.

The name for the ValidatingWebhookConfiguration resource for each CRD will take the following form:
```
<namespace>.<crd-name>.validator[.<component>].apiconnect.ibm.com
```
The following CustomResourceDefinitions utilize a validating webhook:
```
AnalyticsCluster
ApiconnectCluster
GatewayCluster
ManagementCluster
ManagementDBUpgrade
ManagementRestore
PortalCluster
```
Lifecycle
While the validating webhook runtime itself lives within the API Connect Operator pod, the ValidatingWebhookConfiguration is a cluster-scope resource and is stand-alone. When it is created, an ownerReference is set on it that references the API Connect Operator's ClusterRole. Thus, the lifecycle of the ValidatingWebhookConfiguration resources will be linked with the ClusterRole, which is linked with the installation of the operator itself.

When the operator is uninstalled, the ValidatingWebhookConfiguration resources for that operator instance are also removed.

Example

The below output shows the validating webhook configurations created for an operator deployed in the apiconnect-operator namespace. One can be seen for each CRD.

validatingwebhookconfiguration
NAME                                                                               WEBHOOKS   AGE
apiconnect-operator.analyticsclusters.validator.analytics.apiconnect.ibm.com       1          4d4h
apiconnect-operator.apiconnectclusters.validator.apiconnect.ibm.com                1          4d4h
apiconnect-operator.gatewayclusters.validator.gateway.apiconnect.ibm.com           1          4d4h
apiconnect-operator.managementclusters.validator.management.apiconnect.ibm.com     1          4d4h
apiconnect-operator.managementdbupgrades.validator.management.apiconnect.ibm.com   1          4d4h
apiconnect-operator.managementrestores.validator.management.apiconnect.ibm.com     1          4d4h
apiconnect-operator.portalclusters.validator.portal.apiconnect.ibm.com             1          4d4h