CLOUD-727: Bump github.com/cert-manager/cert-manager from 1.16.3 to 1.17.0

[dependabot]

Bumps 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

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 this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[JNKPercona]

Test name	Status
version-service	failure
async-ignore-annotations	passed
auto-config	passed
config	passed
config-router	passed
demand-backup	passed
gr-demand-backup	passed
gr-demand-backup-haproxy	passed
gr-finalizer	passed
gr-haproxy	passed
gr-ignore-annotations	passed
gr-init-deploy	passed
gr-one-pod	passed
gr-recreate	passed
gr-scaling	passed
gr-scheduled-backup	passed
gr-security-context	passed
gr-self-healing	passed
gr-tls-cert-manager	passed
gr-users	passed
haproxy	passed
init-deploy	passed
limits	passed
monitoring	passed
one-pod	passed
operator-self-healing	passed
recreate	passed
scaling	passed
scheduled-backup	passed
service-per-pod	passed
sidecars	passed
smart-update	passed
tls-cert-manager	passed
users	passed
We run 34 out of 34

commit: b355141
image: perconalab/percona-server-mysql-operator:PR-827-b3551417