Sync the release-next branch with master

.github/workflows/check.yaml

@@ -8,7 +8,7 @@ jobs:
   pull-cert-manager-website-verify:
     runs-on: ubuntu-24.04
     steps:
-      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
       - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
         with:
           node-version: 24

.spelling

@@ -538,6 +538,7 @@ runtime
 runtimes
 signoff
 sigstore
+solidserver
 status.condition
 stdout
 subchart

content/docs/concepts/acme-orders-challenges.md

@@ -89,12 +89,37 @@ is a backlog of challenges to complete.
 
 ### Challenge Scheduling
 
-Instead of attempting to process all challenges at once, challenges are
-'scheduled' by cert-manager.
-
-This scheduler applies a cap on the maximum number of simultaneous challenges
-as well as disallows two challenges for the same DNS name and solver type
-(`HTTP01` or `DNS01`) to be completed at once.
-
-The maximum number of challenges that can be processed at a time is 60 as of
-[`ddff78`](https://github.com/cert-manager/cert-manager/blob/ddff78f011558e64186d61f7c693edced1496afa/pkg/controller/acmechallenges/scheduler/scheduler.go#L31-L33).
+Instead of attempting to process all challenges at once, cert-manager
+schedules them.
+
+The scheduler does two things:
+
+- it limits how many challenges can be processed at the same time; and
+- it avoids processing two challenges at once when they would validate the
+  same target.
+
+For conflict detection, cert-manager uses the ACME validation target that is
+actually checked externally:
+
+- `HTTP01` challenges conflict if they validate the same hostname;
+- `DNS01` challenges conflict if they validate the same `_acme-challenge` DNS
+  name.
+
+Different internal solver settings do not make those challenges independent.
+For example, different ingress classes or gateway routes for `HTTP01`, or
+different DNS provider backends for `DNS01`, can still end up validating the
+same hostname or DNS record.
+
+The scheduler does not attempt to model CA-specific rate limits, tenant
+fairness, or ownership policy for DNS names. Deployments that need stronger
+multi-tenant isolation or tighter control over which workloads may request
+certificates for which names should rely on [policy controls](../policy/README.md),
+admission, approval, or separate cert-manager deployments rather than on
+scheduler heuristics alone.
+
+By default, cert-manager processes up to 60 challenges at a time.
+You can change this with the controller
+[`--max-concurrent-challenges`](../cli/controller.md) flag.
+If you install cert-manager with Helm, set `maxConcurrentChallenges`.
+If you use a controller configuration file, set `maxConcurrentChallenges` in
+[`ControllerConfiguration`](../reference/api-docs.md#controller.config.cert-manager.io/v1alpha1.ControllerConfiguration).

content/docs/configuration/acme/README.md

@@ -38,6 +38,14 @@ DNS lookup and can validate that the client owns the domain for the requested
 certificate. With the correct permissions, cert-manager will automatically
 present this TXT record for your given DNS provider.
 
+For more detail on challenge lifecycle, self-checks, and the intentionally
+conservative challenge scheduling and back-pressure behavior, see [ACME Orders
+and Challenges](../../concepts/acme-orders-challenges.md). In shared deployments,
+if you need tighter control over which workloads may request certificates for
+which names, see the [policy documentation](../../policy/README.md). If you are
+debugging a failed issuance flow, see [Troubleshooting Problems with ACME /
+Let's Encrypt Certificates](../../troubleshooting/acme.md).
+
 ## Configuration
 
 ### Creating a Basic ACME Issuer

content/docs/configuration/acme/dns01/README.md

@@ -164,6 +164,7 @@ Links to these supported providers along with their documentation are below:
 - [`cert-manager-alidns-webhook`](https://github.com/DEVmachine-fr/cert-manager-alidns-webhook)
 - [`cert-manager-webhook-abion`](https://github.com/abiondevelopment/cert-manager-webhook-abion)
 - [`cert-manager-webhook-arvan`](https://github.com/kiandigital/cert-manager-webhook-arvan)
+- [`cert-manager-webhook-bunny`](https://github.com/aardbol/cert-manager-webhook-bunny)
 - [`cert-manager-webhook-civo`](https://github.com/okteto/cert-manager-webhook-civo)
 - [`cert-manager-webhook-dnspod`](https://github.com/qqshfox/cert-manager-webhook-dnspod)
 - [`cert-manager-webhook-dnsimple`](https://github.com/neoskop/cert-manager-webhook-dnsimple)
@@ -187,6 +188,7 @@ Links to these supported providers along with their documentation are below:
 - [`cert-manager-webhook-scaleway`](https://github.com/scaleway/cert-manager-webhook-scaleway)
 - [`cert-manager-webhook-selectel`](https://github.com/selectel/cert-manager-webhook-selectel)
 - [`cert-manager-webhook-softlayer`](https://github.com/cgroschupp/cert-manager-webhook-softlayer)
+- [`cert-manager-webhook-solidserver`](https://github.com/niklas-letz/cert-manager-webhook-solidserver)
 - [`cert-manager-webhook-vercel`](https://github.com/rhythmbhiwani/cert-manager-webhook-vercel)
 - [`cert-manager-webhook-yandex-cloud`](https://github.com/malinink/cert-manager-webhook-yandex-cloud)
 - [`cert-manager-webhook-zilore`](https://gitlab.com/zilore/cert-manager-webhook-zilore)

content/docs/configuration/acme/http01/README.md

@@ -15,6 +15,25 @@ Gateway resources, see [Securing Ingress Resources](../../../usage/ingress.md) a
 cert-manager uses your existing Ingress or Gateway configuration in order to
 solve HTTP01 challenges.
 
+## Network Policy Considerations
+
+If your cluster enforces default-deny `NetworkPolicy` rules, make sure that the
+temporary resources created for HTTP01 challenges can still receive traffic.
+
+In particular:
+
+- allow your chosen Ingress controller or Gateway implementation to reach the
+  temporary `acmesolver` Pod and Service created by cert-manager for the
+  challenge response
+- allow the Kubernetes API server to reach the [cert-manager webhook](../../../concepts/webhook.md),
+  because creating and updating ACME resources still goes through admission
+  webhooks
+
+For an overview of the required traffic flows, including the solver path and
+webhook access, read [Network Requirements and Network Policy](../../../installation/best-practice.md#network-requirements-and-network-policy).
+If you are debugging webhook connectivity in a managed environment, also read
+the [webhook troubleshooting guide](../../../troubleshooting/webhook.md).
+
 
 ## Configuring the HTTP01 Ingress solver
 

content/docs/devops-tips/threat-modelling.md

@@ -0,0 +1,93 @@
+---
+title: Threat Model
+description: How we think about permissions and threats in cert-manager
+---
+
+Threat models are industry standard tools for evaluating the security posture of a tool. Since cert-manager is such a privileged tool operating on critical credentials (i.e. X.509 private keys) we think a lot about making cert-manager's security posture coherent while
+remaining powerful and easy to use.
+
+## Third Party Formal Threat Models
+
+ControlPlane did a formal threat model of cert-manager, which is [available free](https://cert-manager.io/docs/announcements/controlplane-2026-cert-manager-hardening-guide.pdf) and which contains a plethora of useful thoughts and actions for practically securing cert-manager - and other tools - in your cluster.
+
+## Threat Model Considerations
+
+The technical considerations for how to think about cert-manager's permissions are deep. Similarly, thinking about how to assign permissions to your users for cert-manager resources is complex.
+
+This section starts with basic learnings which you should apply in your cluster and then seeks to expand on why those recommendations are made.
+
+### Who should be able to interact with cert-manager?
+
+Cluster administrators choose how to grant Kubernetes RBAC permissions to users of a cluster.
+
+We recommend that all administrators restrict cert-manager CRD permissions to only privileged users.
+
+Specifically, for `Certificate`, `CertificateRequest`, `Issuer` and `ClusterIssuer` resources:
+
+- Permission to edit, delete or create should be treated as _highly privileged_ and restricted to the fullest extent possible
+- Permission to view should be minimized in line with general Kubernetes best practices
+- Treat as infrastructure - should be created and updated by humans or automation and generally should not be accessible to running code
+
+For `Order` and `Challenge` resources:
+
+- Permission to edit or create should generally not be widely granted; generally, only cert-manager should be able to modify these resources
+- Permission to view should be minimized in line with general Kubernetes best practices
+
+### Special Considerations for Multi-Tenanted Clusters
+
+In deployments where users are separated by namespaces and are not expected to be able to see any resources for other tenants:
+
+- Ensure that all permissions are tightly namespace scoped and restricted to the fullest possible extent
+- Treat `ClusterIssuer` resources as hazardous, and avoid where possible. Deploy only with a firm threat model in place and strict approval policies.
+- If possible, restrict cert-manager permissions for all tenants and provide cert-manager resources to users as "standard infrastructure"
+- Think carefully about trust chains when using private PKI. Avoid sharing CA certificates between tenants if possible.
+
+### Specific Risks to Consider
+
+This section seeks to explain specific risks which motivate the above advice:
+
+- Permission to create and edit `Issuer` resources in a namespace is equivalent to granting permission to read secrets in that namespace
+    - This is because the `Issuer` can read API tokens for Vault from secrets, and must send those tokens verbatim to the configured server
+    - An attacker with `issuer:create` can therefore send arbitrary keys from a secret to a server they control
+    - This can be mitigated with network egress restrictions to some degree but tightly-scoped RBAC is the ultimate control
+
+- Permission to create / edit `ClusterIssuer` resources grants permission to read secrets in cert-manager's namespace
+    - `ClusterIssuers` can also read API tokens, but are restricted to reading from the cert-manager installation namespace
+    - All cluster-scoped resources (including non-cert-manager resources) should be treated as privileged because of their blast radius if something goes wrong
+
+- Permission to create / edit issuers can allow attackers to make HTTP requests inside the cluster and exfiltrate responses
+    - ACME has several methods by which cert-manager must make a request to a URL which could be attacker controlled
+    - If an attacker can create an ACME issuer, they can set their own server URL and trick cert-manager into making requests inside the cluster
+
+- Permission to create `Challenge` resources can allow attackers to read secrets
+    - Solver configuration can be used to send values from `Secret` resources to attacker-controlled servers
+    - Lower risk, as there's little conceptual reason to share permissions to create `Challenge` resources directly
+
+### Permissions, RBAC and Security Background
+
+cert-manager has cluster-wide permission to create, read and update Kubernetes `Secret` resources by design.
+
+Since certificates are stored in `Secrets` cert-manager needs to be able to check their validity and update them if needed.
+cert-manager has a variety of other privileged permissions which it needs for various tasks; for example, the ability to create `Pod`s for ACME HTTP-01 challenges.
+
+These permissions come with the risk of a "confused deputy" attack where an attacker tries tricking a privileged component into doing tasks on their behalf.
+Since cluster users interact with cert-manager mostly through its custom resources it's very important to consider confused deputy attacks when assigning permissions relating to custom resources to principals in a cluster.
+
+Similarly, SSRF style attacks present risks when attackers are able to trigger cert-manager to issue HTTP requests to other services and (potentially) replay the responses to the attacker.
+
+It is impossible for cert-manager to be a general purpose tool for certificate issuance while also fully mitigating the risk of a confused deputy or SSRF attack.
+For example, if cert-manager is to support talking to arbitrary Vault servers _and_ to support reading Vault API tokens from arbitrary Kubernetes `Secret`s, it _must_ be possible to configure cert-manager to send at least part of arbitrary secrets to any URL.
+
+Put another way: The token must be read from a user-specified `Secret` and then sent in cleartext to a user-specified server URL.
+
+The only possible control for this is to tightly configure who is able to tell cert-manager to perform such actions. This specific example is why we say that the ability to create `Issuer` resources is equivalent to being able to read `Secret` resources.
+
+### Certificates and Trust
+
+Outside of a purely Kubernetes-focused view, cert-manager is obviously closely tied to X.509, TLS and the concept of trust in a certificate hierarchy.
+
+Beyond any specific risks which could arise from allowing users access to freely create cert-manager resources, there are practical considerations which apply generally
+to certificate issuance.
+
+Certificates represent identities, and the production of identities is tightly tied to security generally. There's generally no reason to allow all users in a cluster the
+ability to create arbitrary `Certificate` resources, because attackers may be able to leverage that ability to forge identities and impersonate other users and services.

content/docs/manifest.json

@@ -689,6 +689,10 @@
               "title": "Installing on a Cloud Provider",
               "path": "/docs/installation/compatibility.md"
             },
+            {
+              "title": "Threat Model",
+              "path": "/docs/devops-tips/threat-modelling.md"
+            },
             {
               "title": "Prometheus Metrics",
               "path": "/docs/devops-tips/prometheus-metrics.md"