Larger description in the Feature Track document
Summary:
The Activator should attempt connection to the queue-proxy TLS port and validate the client certificate if TLS is available. If not, it should fall back to the existing HTTP (non-TLS) path.
For certificate validation, the activator may need to be provided with a CA root certificate and a known (per-namespace) SNI target name. If needed, configuration should be added to config-network configmap, or managed as a secret.
Recommended configuration extension for the activator Deployment for alpha to enable mounting secrets if needed (the CA public keys could also be stored in config-network):
spec:
template:
spec:
containers:
- ...
volumeMounts:
- name: client-ca
mountPath: /tls/client-ca
- readOnly: true
volumes:
- name: client-ca
secret:
# Each per-namespace client cert would need to be signed by this CA
secretName: client-ca
optional: true
Larger description in the Feature Track document
Summary:
The Activator should attempt connection to the queue-proxy TLS port and validate the client certificate if TLS is available. If not, it should fall back to the existing HTTP (non-TLS) path.
For certificate validation, the activator may need to be provided with a CA root certificate and a known (per-namespace) SNI target name. If needed, configuration should be added to
config-networkconfigmap, or managed as a secret.Recommended configuration extension for the activator Deployment for alpha to enable mounting secrets if needed (the CA public keys could also be stored in
config-network):