Add DataPlan-Trust implementation for Activator

[davidhadas]

See serving #11906
See https://docs.google.com/document/d/1XE7UzgQlVVtAb7ULSqOyKCaIHtm8zMF35ainp1JmwyY/

This issue focuses on adding DataPlan-Trust support for Activator and Queue including options for:
dataplane-trust = "minimal" (common names for all namespaces)
dataplane-trust = "enabled" (per namespace)
dataplane-trust = "mutual" mTLS

It includes the necessary changes needed for:

1. QP Server will present the DataPlane User Certificate with names "data-plane.knative.dev" and "kn-user-<namespace>"
2. Activator Client will always present the data plane certificate with the name "kn-routing-0"
3. If dataplane-trust = "minimal", Activator Client will verify server certificate has the name "data-plane.knative.dev"
   otherwise, Activator Client will verify server certificate has the name "kn-user-<namespace>"
4. Activator Server will present the DataPlane Routing Certificate with the name "kn-routing-0"
5. If dataplane-trust = "mutual", Activator Server will verify the Client certificate having the name "kn-routing-0"
   Until such time that all ingresses use the new DataPlane Routing certificate, we should also accept "data-plane.knative.dev"

[dprotaso]

As an operator why would I choose minimal over enabled?

[davidhadas]

As an operator why would I choose minimal over enabled?

Minimal equals what we have had as "internal-encryption" (which we deprecated). This is the first TLS support we will be able to release. Once we complete the work for Enabled (all ingress types etc.), enabled will be recommended to replace it.

[nak3]

You will add dataplane-trust = "identity" as well, won't you?

[davidhadas]

You will add dataplane-trust = "identity" as well, won't you?

The code also seems to support what we need for a future dataplane-trust = "identity" since identity adds on top of mutual trust. The main difference between the two appears at the ingress. However, the focus now is on TLS and verifying identities at each hop.

The suggested wip #13969 treats:

• anything that is not disabled, as requiring TLS and server certificate verification
• anything that is not disabled or minimal, as requiring TLS and server certificate verification per namespace
• anything that is not disabled or minimal or enabled as requiring mTLS

So identity and mutual are the same at this point when we make changes to the activator and queue

[dprotaso]

Minimal equals what we have had as "internal-encryption" (which we deprecated).

Given internal encryption is 'alpha' I wonder if we skip supporting Minimal in our redux. It might be better to just remove it now.

@nak3 do you have input on this feature's usage

[nak3]

Yeah, I think it is alright to replace current internal-encryption with enabled if the new configuration will be implemented smoothly.

[davidhadas]

@nak3

Yeah, I think it is alright to replace current internal-encryption with enabled if the new configuration will be implemented smoothly.

I can't see a way to ensure that the new configuration will be implemented smoothly at this point.
Minimal is our only option for enabling support without mandating an activator on-route for all requests.

Enabled without mandating an activator on-route is not something I expect to be available any time soon.

Moving the original internal-encryption forward (now renamed as Minimal) will allow us to introduce end-to-end encryption and move it from Alpha to Beta as soon as the PRs for activator and queue are approved. The other trust levels will evolve at a later time.

[nak3]

If the new configuration will not be implemented smoothly, I think we should keep Minimal.

With said, for moving it from Alpha to Beta, we will add Enabled level configuration as per #11906 ? We will need to re-discuss about Beta criteria if we change the criteria.

[davidhadas]

With said, for moving it from Alpha to Beta, we will add Enabled level configuration as per #11906 ? We will need to re-discuss about Beta criteria if we change the criteria.

#11906 was initially planned to be implemented using internal-encryption which is now called Minimal.
#11906 specifically requires support for "Ingress -> Queue-Proxy" path, which we can only achieve using Minimal

Support for Minimal is therefore in line with the defined criteria, removing "Minimal" means we no longer meet the criteria indicated in #11906.

[nak3]

Sorry I referred to this specific comment #11906 (comment)