build(deps): bump the all group with 3 updates

[dependabot]

Bumps the all group with 3 updates: github.com/cert-manager/cert-manager, github.com/google/cel-go and k8s.io/utils.

Updates github.com/cert-manager/cert-manager from 1.16.3 to 1.17.0

Release notes

Sourced from github.com/cert-manager/cert-manager's releases.

v1.17.0

cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.

v1.17.0 is a feature release with several improvements, including:

• A helpful compliance change to RSA signatures on certificates
• An easier way to specify passwords for PKCS#12 and JKS keystores
• A few feature flag promotions (and a deprecation)
• Dependency bumps and other smaller improvements

Major Themes

RSA Certificate Compliance

The United States Department of Defense published a memo in 2022 which introduced some requirements on the kinds of cryptography they require to be supported in software they use.

In effect, the memo requires that software be able to support larger RSA keys (3072-bit and 4096-bit) and hashing algorithms (SHA-384 at a minimum).

cert-manager supported large RSA keys long before the memo was published, but a quirk in implementation meant that cert-manager always used SHA-256 when signing with RSA.

In v1.17.0, cert-manager will choose a hash algorithm based on the RSA key length: 3072-bit keys will use SHA-384, and 4096-bit keys will use SHA-512. This matches similar behavior already present for ECDSA signatures.

Our expectation is that this change will have minimal impact beyond a slight increase to security and better compliance; we're not aware of Kubernetes based environments which support RSA 2048 with SHA-256 but fail with RSA 4096 and SHA-512. However, if you're using larger RSA keys, you should be aware of the change.

Easier Keystore Passwords for PKCS#12 and JKS

Specifying passwords on PKCS#12 and JKS keystores is supported in cert-manager for compatibility reasons with software which expects or requires passwords to be set; however, these passwords are not relevant to security and never have been in cert-manager.

The initial implementation of the keystores feature required these "passwords" to be stored in a Kubernetes secret, which would then be read by cert-manager when creating the keystore after a certificate was issued. This is cumbersome, especially when many passwords are set to default values such as changeit or password.

In cert-manager v1.17, it's now possible to set a keystore password using a literal string value inside the Certificate resource itself, making this process much easier with no change to security.

For example:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-cert-password
spec:
  secretName: my-cert-password
  issuerRef:
    name: my-issuer
    kind: ClusterIssuer
  keystores:
    jks:
      create: true
      password: "abc123"
    pkcs12:
</tr></table> 

... (truncated)

Commits

• 4562b9a Merge pull request #6657 from rquinio1A/feature/keystore-password-litteral
• c6f3f0c Merge pull request #7527 from SgtCoDFish/upgrade-test-tweaks
• 40cd2a0 Add support for setting literal keystore passwords in Certificates
• 1747743 Merge pull request #7530 from SgtCoDFish/dns-test-integration
• 8233733 split tests using 'live' DNS into separate package
• 5e5ad2f Merge pull request #7529 from SgtCoDFish/bump-base
• a522470 Merge pull request #7428 from jsoref/shorten-skipping-controller-messages
• 2154402 bump base images to latest
• 637eab3 Simplify skipping controller messages
• c003da2 Merge pull request #7428 from jsoref/shorten-skipping-controller-messages
• Additional commits viewable in compare view

Updates github.com/google/cel-go from 0.22.0 to 0.22.1

Release notes

Sourced from github.com/google/cel-go's releases.

Release v0.22.1

Fixes

• Additional hardening on legacy macros [https://redirect.github.com/Additional hardening on legacy macros google/cel-go#1064]
• Additional nil-safety checks with corresponding test updates [https://redirect.github.com/Additional nil-safety checks with corresponding test updates google/cel-go#1073]
• Add two-variable comprehension support to cel-policy [https://redirect.github.com/Add two-variable comprehension support to cel-policy google/cel-go#1074]
• Fix optional test to short-circuit [https://redirect.github.com/Fix optional test to short-circuit google/cel-go#1076]
• Fix nil-type when two-var comprehension has a dyn range [https://redirect.github.com/Fix nil-type when two-var comprehension has a dyn range google/cel-go#1077]

New Contributors

• @​aakash070 made their first contribution in google/cel-go#1069

Full Changelog: google/cel-go@v0.22.0...v0.22.1

Commits

• 933f926 Fix nil-type when two-var comprehension has a dyn range (#1077)
• ff1302f Fix optional test to be functional (#1076)
• 4b73ba3 Add two-variable comprehension support to cel-policy (#1074)
• ba74bf6 Additional nil-safety checks with corresponding test updates (#1073)
• 72e0977 Rename conformance proto import for ease of syncing (#1071)
• 24ec244 Fix format string issue (#1072)
• 7184cb0 Update docs on IO methods (#1070)
• da44524 Expose public methods to convert function and variable decl to v1 Decl (#1069)
• f8ecaa2 Harden legacy macros, add support for existsOne macro (#1064)
• See full diff in compare view

Updates k8s.io/utils from 0.0.0-20241104100929-3ea5e8cea738 to 0.0.0-20241210054802-24370beab758

Commits

• See full diff in compare view

Most Recent Ignore Conditions Applied to This Pull Request

Dependency Name	Ignore Conditions
github.com/google/cel-go	[< 1, > 0.17.7]

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[cert-manager-prow]

Hi @dependabot[bot]. Thanks for your PR.

I'm waiting for a cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[inteon]

/ok-to-test

[inteon]

/approve
/lgtm

[cert-manager-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: inteon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [inteon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment