Support knative-internal-tls in net-contour

[evankanderson]

Larger description in the Feature Track document

Summary:

Contour should support calling activator / backends with a known CA key and subject name (provided by the cluster administrator in config-network for the All Hops Encrypted alpha).

Expected config-network keys:

• activator-ca -- contains the CA public certificate used to sign the activator TLS certificate
• activator-name -- contains the SAN (Subject Alt Name) used to validate the activator TLS certificate

This probably involves setting the spec.routes.services[].protocol and spec.routes.services[].validation fields on the HTTPProxy object

/kind feature-request

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[evankanderson]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[amarflybot]

Is this feature being worked upon ??

[dprotaso]

/assign @KauzClay

@KauzClay landed the changes in #819

I believe what's outstanding is an e2e test in the serving repo.

[dprotaso]

Also from the PR it's important to mention Requires Contour 1.24.0 or greater

This isn't out yet but should be this month.

[amarflybot]

Thanks, this should solve knative/serving#13579
@dprotaso Do you think we could have mtls over http, like istio does?

[dprotaso]

@dprotaso Do you think we could have mtls over http, like istio does?

Right now this change just does TLS between contour and the backend Knative Services. We're effectively automating this step https://projectcontour.io/docs/v1.23.2/config/upstream-tls/

Between which two components/entities do you want mTLS?

[amarflybot]

@dprotaso

Between which two components/entities do you want mTLS?

I am trying to get mTLS setup between contour and the backend Knative Services, the certs are provided by cert-manager, so that the creation and rotation of certificate can happen.
Do you mind sharing some docs over how to setup this?

[KauzClay]

Contour 1.24.0 is out, I tried bringing it in here: #861

[amarflybot]

Hi @KauzClay. I tried using the above version. The certificates are not yet getting used for communication between two knative user-services.
with internal-encryption=true, the services status changes to IngressNotConfigured : Ingress has not yet been reconciled.

[KauzClay]

Hey @amarflybot can you please explain your setup? Are you expecting traffic from a Knative user pod to another via an address like other-ksvc.ns.svc.cluster.local?

If so, internal route traffic has not been encrypted yet. So far, the encryption path is just contour -> activator -> queue proxy.

If you made one Ksvc hit the External address of another Ksvc, I would expect that to work. However, if you want encryption from client -> contour, you would need to enable auto-tls. The certs provided from cert-manager via auto-tls are separate from the certs used in the current implementation of internal-encryption.

If that isn't the case, I'm curious what you're seeing.

[ReToCode]

@amarflybot see also knative/serving#13472.

[amarflybot]

My ingress is contour. So I have net-contour installed. I have cert-manager installed, but it does not make http://other-service.ns.svc.cluster.local , encrypted. i.e. it does not change the url to https. Now the traffic goes from one KN service to other KN service, and I would expect this should be encrypted. If this work as getting tracked under this ticket, then I guess I have to wait for next release.

I believe the svc.cluster.local is handled in especial way and is it not meant to be encrypted?

[amarflybot]

@amarflybot see also knative/serving#13472.

Got it, thanks

[dprotaso]

This was completed here: #1110