Shipping an operator that includes Admission Webhooks

Defining your Webhook in the ClusterServiceVersion

OLM is capable of managing the lifecycle of validating and mutating admission webhooks that are shipped alongside your operator. To this end, the ClusterServiceVersion resource includes a WebhookDefinition object which can be used to define validating and mutating admission webhooks that will be shipped with the operator. For your convenience, an example of a Validating WebhookDefinition can be seen below:

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  annotations:
    description: |-
      An example CSV that contains a webhook
  name: example-webhook.v1.0.0
  namespace: placeholder
spec:
  webhookdefinitions:
  - generateName: example.webhook.com
    type: ValidatingAdmissionWebhook
    deploymentName: "example-webhook-deployment"
    containerPort: 443
    sideEffects: "None"
    failurePolicy: "Ignore"
    admissionReviewVersions:
    - "v1"
    - "v1beta1"
    rules:
    - operations:
      - "CREATE"
      apiGroups:
      - ""
      apiVersions:
      - "v1"
      resources:
      - "configmaps"
    objectSelector:
      foo: bar
    webhookPath: "/validate"
...
...
...

The WebhookDescription object contains a union of the fields defined in the AdmissionWebhook and ValidatingWebhook Kubernetes objects with the exception of the NamespaceSelector, which is generated by OLM to match namespaces scoped by the OperatorGroup that the operator is deployed in.

OLM requires that you define the following:

  • The Type field must be set to ValidatingAdmissionWebhook or MutatingAdmissionWebhook or the CSV will be placed in the failed phase.
  • The CSV must contain a Deployment whose name is equivalent to the value supplied in the DeploymentName field of the WebhookDescription.

Creating an Admission Webhook

When developing an admission webhook that will be managed by OLM you should consider the following constraints.

Certificate Authority Constraints

OLM is configured to provide each deployment with a single Certificate Authority (CA). The logic that generates and mounts the CA into the deployment was originally used by the API Service lifecycle logic. As a result:

  • The tls Cert file will be mounted to the deployment at /apiserver.local.config/certificates/apiserver.crt
  • The tls Key file will be mounted to the deployment at /apiserver.local.config/certificates/apiserver.key

Admission Webhook Rules Constraints

Additionally, in an attempt to prevent operator from configuring the cluster into an unrecoverable state, OLM will place the CSV in the failed phase if the Rules defined in an admission webhook:

  • Intercept requests that target all groups
  • Intercept requests that target the operators.coreos.com group
  • Intercept requests that target the ValidatingWebhookConfigurations or MutatingWebhookConfigurations resources