[pull] master from cert-manager:master - #1066
Open
pull[bot] wants to merge 3912 commits into
Open
Conversation
fix(deps): update cloud go deps (master)
Use samplewebhook image name from tarball manifest
* feat(pkcs12): Support the "Modern2026" profile Signed-off-by: Sean Roberts <seanorama@users.noreply.github.com> * feat(pkcs12): Support the "Modern2026" profile Signed-off-by: Sean Roberts <seanorama@users.noreply.github.com> * feat(pkcs12): Support the "Modern2026" profile Signed-off-by: Sean Roberts <seanorama@users.noreply.github.com> --------- Signed-off-by: Sean Roberts <seanorama@users.noreply.github.com>
- Send full CertificateSpec in SSA Apply() to prevent silent loss of spec fields not in the handpicked set (such as RevisionHistoryLimit) - Strip ManagedFields in serializeApply (matching certificaterequests/apply.go), fixing API server rejection of SSA patches containing metadata.managedFields - Replace test workaround with proper ManagedFields round-trip assertions Signed-off-by: Yuedong Wu <dwcn22@outlook.com>
…ssuing The SSA branch's updateOrApplyStatus was missing FailedIssuanceAttempts from the ApplyStatus payload. The non-SSA UpdateStatus path set all Status fields. The trigger controller reads FailedIssuanceAttempts to calculate issuance retry backoff — without it, retry delays don't work. Signed-off-by: Yuedong Wu <dwcn22@outlook.com>
PR #8808 moved the VerifyCredentials call out of the client constructor (New) into Setup, but this left the vcert connector unauthenticated for two call sites: 1. Setup: Ping ran before VerifyCredentials, sending an unauthenticated request to /vedsdk/ on TPP servers. 2. Sign (CertificateRequest and CertificateSigningRequest controllers): these call New directly and never invoke VerifyCredentials, so certificate requests were sent without an access token, producing: 401 Unauthorized: "Authorization:Bearer parameter is missing or empty." Restore the VerifyCredentials call inside New so that every caller gets an authenticated connector. Keep the call in Setup (now before Ping) so that the AuthFailed condition reason introduced by #8808 continues to work when credentials become invalid between reconciliations. Fixes: https://testgrid.k8s.io/cert-manager-periodics-master#ci-cert-manager-master-e2e-v1-35-issuers-venafi Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Richard Wall <richard.wall@cyberark.com>
Signed-off-by: cert-manager-bot <cert-manager-bot@users.noreply.github.com>
[CI] Merge self-upgrade-master into master
The issuer and clusterissuer controllers watch Secrets and re-reconcile issuers whose credential Secret has changed. The Secret-to-Issuer mapping in checks.go handled TPP and Cloud but was missing the NGTS case, so NGTS issuers were never re-reconciled when their credential Secret was updated. This was introduced in #8779 which added NGTS support but did not update the secret watch mapping. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Richard Wall <richard.wall@cyberark.com>
Fix Venafi issuer auth regression and NGTS Secret watch
Signed-off-by: cert-manager-bot <cert-manager-bot@users.noreply.github.com>
[CI] Merge self-upgrade-master into master
This is because we changed in [1] from using the default GCB service account: 1021342095237@cloudbuild.gserviceaccount.com to using a custom service account: cert-manager-release-gcb@cert-manager-release.iam.gserviceaccount.com When triggering builds (either automatically by pushing a tag, or manually with "Run" in the UI), the following error message would be thrown: Failed to trigger build: if 'build.service_account' is specified, the build must either (a) specify 'build.logs_bucket', (b) use the REGIONAL_USER_OWNED_BUCKET build.options.default_logs_bucket_behavior option, or (c) use either CLOUD_LOGGING_ONLY / NONE logging options: invalid argument Let's use the newer Cloud Logs backend. No point in keeping things in Cloud Bucket. [1]: cert-manager/infrastructure#74 Signed-off-by: Maël Valais <mael@vls.dev>
Build-on-tag now requires a logging option
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
Signed-off-by: cert-manager-bot <cert-manager-bot@users.noreply.github.com>
[CI] Merge self-upgrade-master into master
fix(deps): update cloud go deps (master)
Signed-off-by: cert-manager-bot <cert-manager-bot@users.noreply.github.com>
[CI] Merge self-upgrade-master into master
* Update base images to Debian 13 Signed-off-by: ltwongaa <billy0612.bw@gmail.com> * Update base image tags to Debian 13 Signed-off-by: ltwongaa <billy0612.bw@gmail.com> * Update base_images.mk Signed-off-by: ltwongaa <billy0612.bw@gmail.com> --------- Signed-off-by: ltwongaa <billy0612.bw@gmail.com>
Signed-off-by: cert-manager-bot <cert-manager-bot@users.noreply.github.com>
[CI] Merge self-upgrade-master into master
Cloud Logs only keep logs for 30 days, but I'd rather keep them around longer. Signed-off-by: Maël Valais <mael@vls.dev>
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
…x-deps fix(deps): update golang.org/x deps to v0.21.0 (master)
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
…x-deps fix(deps): update golang.org/x deps to v0.53.0 (master)
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
fix(acme): bound ACME response body size to prevent unbounded-body DoS
…e status The HTTP-01 self-check follows redirects, so the response body may originate from a host other than the one being validated (e.g. an internal service or a cloud metadata endpoint reached via a redirect). The mismatch error was embedded verbatim in Challenge.Status.Reason, which is readable by tenants with access to the Challenge, disclosing fragments of internal responses (CWE-209 / CWE-918). Keep the response body out of the returned error; it is still logged at debug level for operators. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Felix Phipps <fphipps@paloaltonetworks.com>
Address review feedback: the sentinel response bodies must be shorter than the 24-character limit at which the old (removed) code truncated the reflected body, otherwise the "does not reflect body" tests would pass against the buggy implementation too. Add a maxUntruncatedBodyLen constant with an explanatory comment and an assertEffectiveSentinel helper so this is enforced by the tests rather than relying on the comment alone. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Felix Phipps <fphipps@paloaltonetworks.com>
chore(acme): forbid direct construction of the forked ACME client
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
…ommon-name fix(e2e): randomise CommonName in otherName SAN conformance test
…golang.org-grpc-vulnerability chore(deps): update module google.golang.org/grpc to v1.82.1 [security] (master)
issuersForSecret() in pkg/controller/issuers and pkg/controller/clusterissuers duplicated the per-provider DNS-01 solver secretRef list, both between the two controllers and relative to the source of truth in ValidateACMEChallengeSolverDNS01. Flagged independently by Copilot on both files and raised in review: this risks drift if a DNS-01 provider's secretRefs change, potentially reintroducing the stuck Ready=False/InvalidSolver behaviour from #9036 for that provider. Add pkg/acme.RequiredDNS01SolverSecrets, extracted from the existing extractSecrets() helper in pkg/issuer/acme (which already derives the same list from ValidateACMEChallengeSolverDNS01 for the purpose of checking solver Secrets exist), and call it from both issuersForSecret() implementations and from pkg/issuer/acme's validateDNSSolvers(). A new DNS-01 provider's secretRefs now only need wiring into ValidateACMEChallengeSolverDNS01 once for both the admission-validation and requeue-trigger paths to pick them up. Replace the two checks_test.go files' unit tests of the removed per-provider matcher with a higher-level regression test exercising issuersForSecret() end-to-end, covering PrivateKey, EAB, DNS-01 solver, CA and cross-namespace/cross-scope cases. Handle acme.RequiredDNS01SolverSecrets() errors per-issuer rather than aborting issuersForSecret() entirely: converting one issuer's DNS-01 solver config to its internal type is not expected to fail in practice, but propagating that error out of the whole function would have blocked Secret-triggered requeueing for every other issuer too, not just the one that failed to convert. Log and skip that issuer instead, matching the existing pattern in pkg/controller/acmeorders/checks.go. Signed-off-by: Richard Wall <richard.wall@cyberark.com>
TestRequiredDNS01SolverSecrets only exercised Route53 and CloudDNS, even though the whole point of extracting RequiredDNS01SolverSecrets was to keep the requeue-trigger secret list automatically in sync with ValidateACMEChallengeSolverDNS01 as DNS-01 providers change. Without coverage for the other providers, a future change to how one of them collects its secretRefs could silently break the requeue path with nothing in CI to catch it. Add one case each for Akamai, AzureDNS, Cloudflare, AcmeDNS, DigitalOcean and RFC2136, matching the existing Route53/CloudDNS case style. Verified against internal/apis/certmanager/validation/issuer.go to set the minimum fields each provider needs for its secretRef(s) to be collected. Signed-off-by: Richard Wall <richard.wall@cyberark.com>
expectErr was declared in the test table and checked in the test loop, but no case ever set it to true, so the "conversion failed" branch was dead code that gave false confidence the error path was covered. It isn't reachable in practice: RequiredDNS01SolverSecrets' only error comes from api.Scheme.Convert converting the external ACMEChallengeSolver to its internal type, and that conversion (see internal/apis/acme/v1/zz_generated.conversion.go) is generated field-by-field copying with no parsing or validation, so it cannot fail for any value of the external Go struct type. Drop the unused field and branch, and note why in a comment so a future reader doesn't assume the gap is accidental. Signed-off-by: Richard Wall <richard.wall@cyberark.com>
…crets RequiredDNS01SolverSecrets is an exported function in pkg/acme, a non-internal package, but returned []*internal/apis/meta.SecretKeySelector - an internal/... type. Any consumer of this module outside github.com/cert-manager/cert-manager cannot import that internal package, so it could receive the return value but never name its element type directly. Flagged by Copilot on re-review. Convert each internal SecretKeySelector to the external pkg/apis/meta/v1 type (identical Name/Key shape, existing generated conversion function) before returning, so the public function only ever exposes public types. No caller needed to change: every call site only accesses the exported Name/Key fields, which behave the same whether the slice holds pointers or values. Signed-off-by: Richard Wall <richard.wall@cyberark.com>
pkg/controller/clusterissuers/checks.go logged "for issuer %s" when handling a solver-secret conversion error for a ClusterIssuer, unlike the equivalent message in pkg/controller/issuers/checks.go which correctly names its resource kind. Flagged by Copilot on re-review: using the generic term here makes it harder to tell which controller logged the error when diagnosing. Signed-off-by: Richard Wall <richard.wall@cyberark.com>
…igration (#9041) * fix(e2e): resolve bestpractice-install failures after Kyverno 3.8.1 migration ci-cert-manager-master-e2e-v1-36-bestpractice-install has failed every periodic run since 2026-07-09, immediately after the Kyverno ClusterPolicy to ValidatingPolicy migration in #8886 bumped the chart to 3.8.1. Two distinct problems, fixed below. 1. Webhook startup race: Kyverno registers its own admission webhooks from inside the running pod, after `helm upgrade --wait` already considers the Deployment ready. The very next step, `kubectl apply` of policy.yaml, lands in that startup window and fails with a webhook connection-refused error, aborting e2e-setup-kyverno before a single test runs: Error from server (InternalError): Internal error occurred: failed calling webhook "validate-policy.kyverno.svc": failed to call webhook: Post "https://kyverno-svc.kyverno.svc:443/policyvalidate ?timeout=10s": dial tcp 10.0.255.124:443: connect: connection refused Fixed by retrying the apply with a short backoff, mirroring the retry already used for tool downloads via curl's --retry-connrefused in make/_shared/tools/00_mod.mk. The retry loop also captures combined stdout+stderr and prints it on every failed attempt rather than only the last, so the real error is visible immediately instead of after the full retry budget. 2. ServiceAccount-targeting policy is a different policy, not a CEL rewrite of the original: fixing (1) let the suite actually run, surfacing that #8886 also changed the effective automount policy from validating Pods (spec.automountServiceAccountToken) to validating ServiceAccounts themselves (object.automountServiceAccountToken). This is because the pre-migration policy, other/restrict-automount-sa-token, has no like-for-like CEL/ValidatingPolicy equivalent upstream - the only automount-related entry in kyverno's other-vpol catalog is restrict-sa-automount-sa-token, a differently-scoped policy that happens to have a similar name. Enforcing that policy as published denies Kubernetes' own creation of the "default" ServiceAccount for every namespace, since nothing sets automountServiceAccountToken on it. kube-controller-manager's serviceaccounts_controller retries forever and is denied every time (confirmed via its own logs: 4576 denials across 852 e2e namespaces in one run), so this is a permanent failure, not a race - any Pod anywhere that doesn't specify a custom ServiceAccount is unable to run. It reached 161 failing e2e specs here (RBAC-boundary, ACME HTTP01, Vault issuer suites - i.e. every suite that creates a Pod or ServiceAccount without setting the field), traced via 110 direct denial events in the apply log plus the default-ServiceAccount denials above: error creating ServiceAccount for Kubernetes auth: admission webhook "vpol.validate.kyverno.svc-fail" denied the request: Policy restrict-sa-automount-sa-token failed: ServiceAccounts must set automountServiceAccountToken to false. Fixed by patching the migrated ValidatingPolicy in kustomization.yaml to restore the original Pod-targeting semantics (resourceRules on pods, CEL expression on spec.automountServiceAccountToken) instead of the ServiceAccount-targeting resource kyverno currently publishes. This matches the policy already in effect on 2026-07-08 before the migration, under which the entire e2e suite already passed cleanly (479/479, 0 failures) - cert-manager's own ACME HTTP01 solver pod already sets automountServiceAccountToken: false (pkg/issuer/acme/http/pod.go), so no further e2e or product code changes are needed. Also fixes a related, unrelated-looking symptom this surfaced: CreateKubeNamespace in the e2e framework created the test Namespace and returned immediately, without waiting for its "default" ServiceAccount to be provisioned - a latent race any Pod created immediately afterwards (e.g. an ACME HTTP01 solver pod) could hit. Kept as defence in depth, mirroring the equivalent, long-standing wait in Kubernetes' own e2e framework (WaitForDefaultServiceAccountInNamespace, called from CreateTestingNS), even though it no longer fires in practice once the ServiceAccount-targeting denial above is fixed. Fixes: https://testgrid.k8s.io/cert-manager-periodics-master#ci-cert-manager-master-e2e-v1-36-bestpractice-install Signed-off-by: Richard Wall <richard.wall@cyberark.com> * adding changes to description and subject Signed-off-by: Hemant Joshi <mail@hjoshi.me> --------- Signed-off-by: Richard Wall <richard.wall@cyberark.com> Signed-off-by: Hemant Joshi <mail@hjoshi.me> Co-authored-by: Hemant Joshi <mail@hjoshi.me>
fix(acme): don't reflect HTTP-01 self-check response body in Challenge
…ity] Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
Create with FieldManager records ownership as operation:Update. Use Apply when ServerSideApply is enabled so create ownership matches updates (operation:Apply). Add create/update Apply payload tests. Signed-off-by: Yuedong Wu <dwcn22@outlook.com>
Add issuing unit test that ApplyStatus includes the field on failure and omits it on success, and an integration test that scalar status fields clear by omission only when solely owned. Signed-off-by: Yuedong Wu <dwcn22@outlook.com>
fix: ServerSideApply field loss in certificate-shim and issuing controller
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
hjoshi123 asked for an in-tree TODO so the O(numIssuers) Secret-event scan and per-ACME RequiredDNS01SolverSecrets cost are not forgotten after the Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca> #9036 re-queue fix lands. Follow-up: index by referenced Secret names.
…com-google-cel-go-vulnerability chore(deps): update module github.com/google/cel-go to v0.29.0 [security] (master)
…o-gateway-api-1.x chore(deps): update module sigs.k8s.io/gateway-api to v1.6.1 (master)
fix(deps): update cloud go deps (master)
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
…-go-patches fix(deps): update kubernetes go patches to v0.36.3 (master)
…concile Re-queue Issuer/ClusterIssuer on ACME DNS-01 solver Secret events
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
…odules chore(deps): update makefile modules to 57b5681 (master)
Signed-off-by: Renovate Bot <renovate-bot@users.noreply.github.com>
…odules chore(deps): update makefile modules to e0878ff (master)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )