Skip to content

Move Enterprise-only webhook rendering into the extension - #5206

Open
caseydavenport wants to merge 2 commits into
tigera:masterfrom
caseydavenport:casey-devariant-webhooks-2
Open

Move Enterprise-only webhook rendering into the extension#5206
caseydavenport wants to merge 2 commits into
tigera:masterfrom
caseydavenport:casey-devariant-webhooks-2

Conversation

@caseydavenport

Copy link
Copy Markdown
Member

Description

Follow-up to #5164, moving the rest of the Enterprise-only webhook rendering behind the extensions boundary. The base render now produces the same objects for both variants, and the Enterprise extension layers on:

  • audit logging, both the webhook registration and the host directory the container writes it to
  • the mutating webhook configuration and the UISettings webhook in it
  • permissions on managed clusters and UI settings groups
  • a root (and on OpenShift, privileged) security context on the container

When the operator runs as Calico, the mutating webhook configuration is queued for deletion so an install downgraded from Enterprise cleans up after itself.

One behavior change worth calling out: Calico installs no longer mount the audit log host directory into the webhooks container. Only the Enterprise audit handler ever wrote there, so it was a mounted-but-unused hostPath, but dropping it does roll the webhooks deployment on upgrade.

Release Note

None

The audit-logs hostPath volume moves too, since only Enterprise writes there.
Comment thread pkg/enterprise/apiserver/webhooks.go Outdated
// modifyWebhooks layers audit logging, the mutating webhooks, the extra RBAC, and
// management-cluster support onto the rendered objects.
func modifyWebhooks(cfg *webhooks.Configuration, managementCluster *operatorv1.ManagementCluster, multiTenant bool, create, del []client.Object) ([]client.Object, []client.Object) {
if dep, ok := extensions.FindObject[*appsv1.Deployment](create, webhooks.WebhooksName); ok {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably want to panic or be very very load if we couldn't find an object through the extensions.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added extensions.MustFindObject, which panics with BUG: no object named %q to modify when the base render did not produce it, mirroring render.MustContainer in pkg/render/containers.go. Converted the four lookups here that are always guaranteed to hit.

Your point applies to the whole mechanism though - there are about 20 other if ok sites across pkg/enterprise/ that silently no-op the same way. I'll do those in a separate PR, minus guardian.go:46, kubecontrollers.go:62, and apiserver/extension.go:733, which return early on a miss deliberately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants