certgen: add cert-manager certificate compatibility

[jpeach]

This change adds new options to certgen that will allow it to overwrite
existing Kubernetes Secrets, and to generate Secrets in a format that
is compatible with cert-manager (we call this "compact" format).

The --overwrite flag can be used to let certgen update existing secrets,
and this will enable both the transition to the new format and certificate
rotation on a per-release granularity.

The --secrets-format flag switches the Secrets output format from the
current format to the compatible "compact" format. Once this is enabled
in the deployment YAML, operators will easily be able to substitute
cert-manager certificates for certgen certificates.

Finally, the bootstrap command is updated to ensure that the specified
certificate files are actually present. This prevents Envoy starting up
and rejecting the static configuration, which is unrecoverable.

This fixes #2494.

Signed-off-by: James Peach [email protected]

[jpeach]

@tsaarni This PR adds all the machinery for xDS certificate rotation and transitioning to xDS Secrets that are compatible with cert-manager. Would be great if you could do a review pass.

[codecov]

Codecov Report

Merging #2547 into master will increase coverage by 0.92%.
The diff coverage is 36.03%.

@@            Coverage Diff             @@
##           master    #2547      +/-   ##
==========================================
+ Coverage   76.84%   77.77%   +0.92%     
==========================================
  Files          72       71       -1     
  Lines        5892     5893       +1     
==========================================
+ Hits         4528     4583      +55     
+ Misses       1264     1206      -58     
- Partials      100      104       +4     

Impacted Files	Coverage Δ
cmd/contour/certgen.go	31.94% <18.51%> (+31.94%)	⬆️
internal/certgen/certgen.go	34.44% <40.78%> (+34.44%)	⬆️
internal/envoy/bootstrap.go	87.66% <50.00%> (-1.53%)	⬇️

[jpeach]

@stevesloka @youngnick With the "compact" secrets format, should we still create the cacert secret with a single ca.crt data element?

[youngnick]

@stevesloka @youngnick With the "compact" secrets format, should we still create the cacert secret with a single ca.crt data element?

If that will help with migration, yes, otherwise, no.

[youngnick]

LGTM aside from changing CheckFiles default to false, probably with a name change.

[jpeach]

@stevesloka @youngnick With the "compact" secrets format, should we still create the cacert secret with a single ca.crt data element?

If that will help with migration, yes, otherwise, no.

Pretty sure it's not needed for migration.

[youngnick]

LGTM