Support internal-encryption to deploy internal certificates automatically

[nak3]

Currently users have to deploy certificates manually with several options such as
activator-san, activator-ca, queue-proxy-ca etc.

Such deployment and management of the certificates is a big burden for users.

Hence, this patch supports internal-encryption config to deploy
internal certificates automatically.

knative-extensions/net-kourier#855 and knative/serving#13005 demonstrated this change.

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nak3

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [nak3]

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

[codecov]

Codecov Report

Merging #680 (28356d9) into main (edfa211) will decrease coverage by 0.09%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #680      +/-   ##
==========================================
- Coverage   94.85%   94.75%   -0.10%     
==========================================
  Files          41       41              
  Lines        1243     1221      -22     
==========================================
- Hits         1179     1157      -22     
  Misses         52       52              
  Partials       12       12              

Impacted Files	Coverage Δ
pkg/config/config.go	84.81% <100.00%> (-1.86%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update edfa211...28356d9. Read the comment docs.

[nak3]

/cc @evankanderson @psschwei @skonto @rhuss

net-kourier's unit test is failing but it can be fixed as knative-extensions/net-kourier#855
Note, I dropped the old configurations but the alpha feature can be dropped without notice https://knative.dev/docs/serving/configuration/feature-flags/#lifecyle

[skonto]

I guess all that will be in the knative-serving-certs and SAN is set to data-plane.knative.dev

[evankanderson]

Should the SAN include a per-namespace component?

[skonto]

LGTM let's wait for @evankanderson's approval.

[psschwei]

Note, I dropped the old configurations but the alpha feature can be dropped without notice https://knative.dev/docs/serving/configuration/feature-flags/#lifecyle

My initial thought was issue to mark the old configs as deprecated for a release and then drop them in the next one, but it looks like these flags were only added a couple of months ago in #648 , so don't think there's any problem with dropping.

[evankanderson]

I love the simplification in configuration! One concern -- I think we should have different SANs per-namespace, to prevent any sort of network-confusion attacks

[evankanderson]

Should the SAN include a per-namespace component?

[evankanderson]

Note, I dropped the old configurations but the alpha feature can be dropped without notice https://knative.dev/docs/serving/configuration/feature-flags/#lifecyle

My initial thought was issue to mark the old configs as deprecated for a release and then drop them in the next one, but it looks like these flags were only added a couple of months ago in #648 , so don't think there's any problem with dropping.

I'm sort of in the same boat as Paul here -- I could go either way given how new this is and how hard the old way was to set up.

I think my larger / largest concern about keeping vs dropping values is whether it makes it hard to integrate from this repo to the net-kourier repo.

[evankanderson]

/lgtm

[evankanderson]

(since the SAN is not actually specified in this PR, just mentioned by @skonto 's comment)