Skip to content

feat(netpols): ship the cert-manager-webhook-linode allow-rule - #3473

Open
aweingarten wants to merge 5 commits into
linode:mainfrom
aweingarten:feat/cert-manager-webhook-linode-network-policy
Open

feat(netpols): ship the cert-manager-webhook-linode allow-rule#3473
aweingarten wants to merge 5 commits into
linode:mainfrom
aweingarten:feat/cert-manager-webhook-linode-network-policy

Conversation

@aweingarten

Copy link
Copy Markdown
Contributor

📌 Summary

Second of #3387, after #3470 (ESO webhook). Same shape, different component.

Under default-deny the apiserver's discovery probe to the linode DNS-01 solver webhook (:443) is dropped, so the aggregated APIService v1alpha1.acme.slicen.me stays Available=False with FailedDiscoveryCheck. Convergence then hangs waiting on a certificate that can never be issued — and nothing in that symptom points at a NetworkPolicy.

This one can't be fixed by widening an existing policy. The webhook comes from the cert-manager-webhook-linode chart, which labels its pods app: cert-manager-webhook-linode with no app.kubernetes.io/name. The cert-manager chart's own webhook policy (charts/cert-manager/templates/networkpolicy-webhooks.yaml) selects app.kubernetes.io/name: webhook + component: webhook, which is correct for cert-manager's webhook and shouldn't be loosened to catch a different chart's pods. So this gets its own rule.

Adds netpols.certManagerWebhookLinode, driven by apps.cert-manager.networkPolicies.enabled (default false), rendered only when linode is the configured DNS provider — the only case where the webhook is installed at all.

🔍 Reviewer Notes

  • Verified against the rendered chart, not assumed. helm template charts/cert-manager-webhook-linode gives pod labels {app: cert-manager-webhook-linode, release: cert-manager-webhook-linode}, container port 443 (https), and APIService v1alpha1.acme.slicen.me → service cert-manager-webhook-linode.cert-manager.
  • Same ports-only rationale as feat(netpols): ship the ESO webhook allow-rule #3470: the apiserver is off the pod network on a managed control plane, so there's no namespaceSelector/ipBlock that can express it. Same offer — if you'd rather pin it to the LKE control-plane range, easy change.
  • Double-gated on purpose. and (networkPolicies.enabled) (hasKey dns.provider "linode") — enabling cert-manager netpols on a cluster using a different DNS provider shouldn't create a policy selecting pods that don't exist.
  • Default false for the same reason as feat(netpols): ship the ESO webhook allow-rule #3470: the policy is pod-scoped and Ingress-typed, so creating it makes those pods deny any ingress not listed — only the intent on a cluster already running default-deny.
  • Verified renders with the flag on, nothing with it off, helm lint clean both ways.

Remaining #3387 gaps after this

  1. CNPG operator → Harbor DB (8000 instance status, 9187 metrics), cross-namespace.
  2. Istio sidecar egress to istiod (15010/15012/15014) — the one with the nastiest failure mode, since a dead Envoy takes all pod egress with it.
  3. LKE-E apiserver egress on 6443 — not a single rule but a constraint on every policy that talks to the apiserver (the in-cluster kubernetes Service maps 443→targetPort 6443 and Cilium evaluates policy after kube-proxy-replacement DNAT, so a rule allowing only 443 is silently dropped). Probably deserves its own issue.

🧹 Checklist

  • Code is readable, maintainable, and robust.
  • Unit tests added/updated — n/a, chart-template change; verified via helm lint/helm template against the rendered webhook chart

Under default-deny the apiserver's discovery probe to the linode DNS-01
solver webhook (:443) is dropped, so the aggregated APIService
`v1alpha1.acme.slicen.me` stays Available=False with
FailedDiscoveryCheck. Convergence then hangs waiting on a certificate
that can never be issued, and nothing in the symptom points at a
NetworkPolicy.

The webhook can't be covered by the policy that already exists: it is
deployed by the cert-manager-webhook-linode chart, which labels its pods
`app: cert-manager-webhook-linode` with no `app.kubernetes.io/name`,
while the cert-manager chart's own webhook policy selects
`app.kubernetes.io/name: webhook`. That selector is right for
cert-manager's own webhook, so this gets its own rule rather than a
widened one.

Adds `netpols.certManagerWebhookLinode`, driven by
`apps.cert-manager.networkPolicies.enabled` (default false) and only
rendered when linode is the configured DNS provider, since that is the
only case in which the webhook is installed at all.

Refs linode#3387
Copilot AI lite review requested due to automatic review settings August 3, 2026 14:25

Copilot AI left a comment

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.

Pull request overview

Adds an opt-in NetworkPolicy allow-rule for the cert-manager-webhook-linode aggregated APIService webhook so clusters running default-deny policies don’t block the kube-apiserver discovery probe to the webhook on port 443 (preventing FailedDiscoveryCheck / stalled cert issuance).

Changes:

  • Introduces netpols.certManagerWebhookLinode, gated by apps.cert-manager.networkPolicies.enabled and only enabled when the Linode DNS provider is configured.
  • Adds a new NetworkPolicy template in the cert-manager namespace selecting app: cert-manager-webhook-linode and allowing ingress on TCP/443.
  • Exposes apps.cert-manager.networkPolicies in schema + defaults to support the new gating flag.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
values/apl-network-policies/apl-network-policies.gotmpl Computes netpols.certManagerWebhookLinode based on cert-manager NP enablement and Linode DNS provider presence.
values-schema.yaml Allows apps.cert-manager.networkPolicies via appNetworkPolicyConfig.
helmfile.d/snippets/defaults.yaml Sets default apps.cert-manager.networkPolicies.enabled: false.
charts/apl-network-policies/values.yaml Documents the new cert-manager-webhook-linode policy toggle and behavior.
charts/apl-network-policies/templates/networkpolicies/cert-manager-webhook-linode.yaml Adds the actual NetworkPolicy manifest enabling TCP/443 ingress to the Linode solver webhook pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cert-manager-webhook-linode-policy
# - Allows ingress from:
# * anywhere on 443 — the apiserver's discovery probe for the aggregated APIService, which has
# no address a selector or ipBlock can pin down on a managed control plane
# - Only rendered when linode is the configured DNS provider
Copilot AI review requested due to automatic review settings August 3, 2026 14:36

Copilot AI left a comment

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.

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

charts/apl-network-policies/templates/networkpolicies/cert-manager-webhook-linode.yaml:7

  • The new NetworkPolicy name doesn’t follow the established *-platform-policy naming used by the other policies in this chart (e.g. git-server-platform-policy, gitea-platform-policy, otomi-api-platform-policy). Aligning the name keeps resources consistent and easier to locate/grep.
metadata:
  name: cert-manager-webhook-linode-policy
  namespace: cert-manager

Copilot AI review requested due to automatic review settings August 4, 2026 07:09

Copilot AI left a comment

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.

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants