Describe the feature
User story: As a user, I want all my traffic to be encrypted throughout the Knative routing path, so that any data going over that path is not readable for anybody else and make my environment more secure.
Business justification: Currently containers running as Knative service must communicate using HTTP/1.1 without any encryption, and in case there is encryption this terminates at the knative-serving side rather than at the container level (thus not achieving full end-to-end encryption and failing some security standards). Supporting passthrough/re-encrypt in the ingress for serverless would enable this feature and make customer's environments more secure.
Acceptance Criteria:
GIVEN I have deployed a service using knative
WHEN I have created a certificate to encrypt incoming external traffic
AND created a "secret" and necessary networking configuration
THEN I am accessing my serverless application by using a secure connection that is now trusted by the CA
Things to consider:
- Need to be enabled / enable-able for all Ingress implementations
- Need to cover 3 paths:
- Ingress -> Queue-Proxy when scaled above TargetBurstCapacity extra capacity. If this was the only part implemented, it would prevent scale-to-zero.
- Needed for scale-to-zero:
- Ingress -> Activator - Needs the ability to change HTTP headers to record traffic split decision.
- Activator -> Queue-Proxy
-Should we support ONE certificate for all services?
- Do individual certificates per service for now.
- Certification rotation can also be used.
- Reencryption or passthrough either would be acceptable.
Implementation tasks for Alpha:
Describe the feature
User story: As a user, I want all my traffic to be encrypted throughout the Knative routing path, so that any data going over that path is not readable for anybody else and make my environment more secure.
Business justification: Currently containers running as Knative service must communicate using HTTP/1.1 without any encryption, and in case there is encryption this terminates at the knative-serving side rather than at the container level (thus not achieving full end-to-end encryption and failing some security standards). Supporting passthrough/re-encrypt in the ingress for serverless would enable this feature and make customer's environments more secure.
Acceptance Criteria:
GIVEN I have deployed a service using knative
WHEN I have created a certificate to encrypt incoming external traffic
AND created a "secret" and necessary networking configuration
THEN I am accessing my serverless application by using a secure connection that is now trusted by the CA
Things to consider:
- Ingress -> Queue-Proxy when scaled above TargetBurstCapacity extra capacity. If this was the only part implemented, it would prevent scale-to-zero.
-Should we support ONE certificate for all services?
Implementation tasks for Alpha: