gateway-provisoner: customize the cert's lifetime

[izturn]

Signed-off-by: Gang Liu [email protected]

In the past, we could only use 'Certgen' to set the lifetime, this PR has added the new way to set it through provisioner

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.77%. Comparing base (808864b) to head (1766f9f).
Report is 62 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6604   +/-   ##
=======================================
  Coverage   81.76%   81.77%           
=======================================
  Files         133      133           
  Lines       15944    15947    +3     
=======================================
+ Hits        13037    13040    +3     
  Misses       2614     2614           
  Partials      293      293           

Files with missing lines	Coverage Δ
internal/provisioner/controller/gateway.go	59.40% <100.00%> (+0.34%)	⬆️
internal/provisioner/model/model.go	100.00% <100.00%> (ø)
internal/provisioner/objects/secret/secret.go	48.43% <100.00%> (ø)

[tsaarni]

Looks good to me, few comments inline.

[tsaarni]

I tested the change and it worked great, both contourcert and envoycert were getting the configured expiry period.

I still added some more suggestion to rephrase the documentation, since I thought there might be a chance of misunderstanding what certificates are being discussed, especially for those who do not use Gateway API.

Looking at the existing docs, it seems to me we might have a gap describing the auto-generated xDS certificates in context of Gateway API and how to life-cycle manage them. Being able to set expiry via certLifetime is good but it should preferably be clearly documented that the gateway provisioner has no capability to renew every certLifetime days - we could create a new issue for that.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Ensure your PR is passing all CI checks. PRs that are fully green are more likely to be reviewed. If you are having trouble with CI checks, reach out to the #contour channel in the Kubernetes Slack workspace.
• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[izturn]

ping @tsaarni

[tsaarni]

Thanks @izturn, looks good to me!

I wonder if others want to still to comment, especially those who are actively using Gateway API in their production (unlike me)?

[izturn]

@skriss @sunjayBhatia , WDYT?

[tsaarni]

An additional thought occurred to me regarding the API changes. I'm speculating here, but imagine that in the future, the gateway-provisioner might support Cert-manager instead of certgen. It could create Cert-manager CRs for Contour and Envoy, allowing Cert-manager to handle certificate management. With that in mind, are we introducing anything in this PR that could make it harder to add support for Cert-manager in the API later on?

• When Cert-manager support is introduced, there would likely need to be at least one additional certificate-related parameter—a field where users can choose between certgen and cert-manager.
• Cert-manager defaults to 90 days for certificate lifetimes and supports duration down to 1 hour, while certgen defaults to 365 days.

It might be easier to support future attributes if we group certificate-related fields into a struct, rather than adding them all flat under ContourSettings.

More specifically, XDS certificates aren't purely a Contour setting since they also impact Envoy. I understand that the current field naming under ContourDeployment.spec.contour.certLifetime is a compromise, but if we anticipate more certificate-related parameters, perhaps something like ContourDeployment.spec.certificates could make sense as well?

Similar to certgen, Cert-manager allows configuring certificate lifetimes via the Certificate.spec.duration field. The certLifetime parameter could potentially control this in the future. However, Cert-manager supports Go duration units, with a minimum value of 1h, not just days. The current field in this PR uses days and defaults to 365, but since this is only documented in the comments, the default could change in the future if Cert-manager is selected.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Ensure your PR is passing all CI checks. PRs that are fully green are more likely to be reviewed. If you are having trouble with CI checks, reach out to the #contour channel in the Kubernetes Slack workspace.
• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Ensure your PR is passing all CI checks. PRs that are fully green are more likely to be reviewed. If you are having trouble with CI checks, reach out to the #contour channel in the Kubernetes Slack workspace.
• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Ensure your PR is passing all CI checks. PRs that are fully green are more likely to be reviewed. If you are having trouble with CI checks, reach out to the #contour channel in the Kubernetes Slack workspace.
• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack