serving

serving copied to clipboard

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:

• [x] https://github.com/knative/serving/issues/12501
• [x] https://github.com/knative/serving/issues/12502
• [x] https://github.com/knative/serving/issues/12503
• [x] https://github.com/knative-sandbox/net-kourier/issues/750
• [x] https://github.com/knative-sandbox/net-contour/issues/703
• [ ] TODO: integration work on control plane once data plane components are implemented (force activator always in path)

found a similar issue : adding it here : Encrypt traffic on the data-path "natively"

Our answer for this has always been "sounds like you want to use istio". Is this really a Knative specific feature?

As long as this doesn't get extended to adding support for an ocean of access control schemes, authentication mechanisms, etc. (in other words, sticking with TLS encryption only) I think this could be manageable.

I didn't look into the details, but @slinkydeveloper did experiment with a fully-automated PKI in the context of control-protocol at https://github.com/knative-sandbox/control-protocol/tree/release-0.25/pkg/certificates. The Kafka channel implementation in the Eventing sandbox uses it already.

Hello Scott, Sorry for the late reply. My 2 cents. Knative serving (scale to zero and in turn the operational efficiencies) is very attractive, especially to Financial institutions , however, if we cannot offer the basic TLS security requirements natively and force the use of Mesh just for this use case. We increase the extra hop and overhead and in turn add a con on using knative. One of the reasons we decided to move to Kourier is to remove dependency on Istio.

Hello Antoine, TLS encryption is the goal of this request. I will take a look at the info you provided.

Thank you, -N

On Mon, 6 Sept 2021 at 04:50, Antoine Cotten @.***> wrote:

As long as this doesn't get extended to adding support for an ocean of access control schemes, authentication mechanisms, etc. (in other words, sticking with TLS encryption only) I think this could be manageable.

I didn't look into the details, but @slinkydeveloper https://github.com/slinkydeveloper did experiment with a fully-automated PKI in the context of control-protocol at https://github.com/knative-sandbox/control-protocol/tree/release-0.25/pkg/certificates. The Kafka channel implementation in the Eventing sandbox uses it https://github.com/knative-sandbox/eventing-kafka/tree/release-0.25/pkg/common/controlprotocol already.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/knative/serving/issues/11906#issuecomment-913467962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AISZCFDESFZHQ6KODTB4P3DUAR6FDANCNFSM5DKG5AZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Hello folks, We have started a feature track for this. https://docs.google.com/document/d/1XE7UzgQlVVtAb7ULSqOyKCaIHtm8zMF35ainp1JmwyY/edit?resourcekey=0-e1MXRxQaalq-EHW46ZCCWg#heading=h.n8a530nnrb

Please feel free to add/edit and raise concerns in the doc.

Thank you, Thank you, -N

On Thu, 9 Sept 2021 at 11:51, Naina Singh @.***> wrote:

Hello Scott, Sorry for the late reply. My 2 cents. Knative serving (scale to zero and in turn the operational efficiencies) is very attractive, especially to Financial institutions , however, if we cannot offer the basic TLS security requirements natively and force the use of Mesh just for this use case. We increase the extra hop and overhead and in turn add a con on using knative. One of the reasons we decided to move to Kourier is to remove dependency on Istio.

Hello Antoine, TLS encryption is the goal of this request. I will take a look at the info you provided.

Thank you, -N

On Mon, 6 Sept 2021 at 04:50, Antoine Cotten @.***> wrote:

As long as this doesn't get extended to adding support for an ocean of access control schemes, authentication mechanisms, etc. (in other words, sticking with TLS encryption only) I think this could be manageable.

I didn't look into the details, but @slinkydeveloper https://github.com/slinkydeveloper did experiment with a fully-automated PKI in the context of control-protocol at https://github.com/knative-sandbox/control-protocol/tree/release-0.25/pkg/certificates. The Kafka channel implementation in the Eventing sandbox uses it https://github.com/knative-sandbox/eventing-kafka/tree/release-0.25/pkg/common/controlprotocol already.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/knative/serving/issues/11906#issuecomment-913467962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AISZCFDESFZHQ6KODTB4P3DUAR6FDANCNFSM5DKG5AZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

There was additional discussion in #11239 that might be worth reading when considering the proposal.

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.

I believe we have an alpha (and maybe beta) design for this in the Feature Track document along with a list of parallel items for networking WG to engage with upstream gateway-api on supporting TLS to upstream (backendRef) services.

a list of parallel items for networking WG to engage with upstream gateway-api on supporting TLS to upstream (backendRef) services.

Upstream gateway-api is planning to support the TLS to upstream service by the "extension" for now. They will clarify it by https://github.com/kubernetes-sigs/gateway-api/issues/968

• TODO: integration work on control plane once data plane components are implemented (force activator always in path)

Hi @evankanderson, @nainaz I'm trying to find out what is left to be done for this feature to complete in alpha. I'm unsure what is meant by the marked sentence. Could you clarify a bit?

Also do we need a tracking issue for net-gateway-api (as soon as the work Kenjiro mentioned is done).

Furthermore, what about net-istio? What should happen if the feature is enabled (also when it will be always on in GA) in case of

• net-istio is installed and service mesh is enabled? As service mesh would already take care of encryption?
• net-istio is installed but just as an ingress controller?

Thanks for clarifying. /cc @nak3

Hello!

We needed two implementations to consider this a feasible approach.

I believe that @KauzClay has recently wrapped up the contour implementation, giving us this validation, allowing the feature to move to the beta implementation gate. At this point, we'd want to ensure implementation on the remaining plugins, integration testing to ensure consistency, and make a plan for rollout as a default-on feature for a GA release.

I know that net-gateway-api will currently be a problem, as there's no way to indicate through the Gateway API surface that an HTTPRoute backend uses a particular TLS cert, or even that a backend uses TLS.

I'll need to verify for Istio in non-mesh mode, but I suspect that setting up a DestinationRule is how to do it.

@evankanderson, @nak3 what do you think about this proposal for going forward:

Alpha (disabled by default)

• https://github.com/knative/serving/issues/14215
• Activator should not need a restart (https://github.com/knative/serving/issues/13694)
• https://github.com/knative/serving/issues/14187
• https://github.com/knative/serving/issues/14219
• Finish implementation in net-contour https://github.com/knative-sandbox/net-contour/issues/703 (if anything left)
• Implement net-istio (https://github.com/knative-sandbox/net-istio/issues/1063)
• Implement net-gateway-api (https://github.com/knative-sandbox/net-gateway-api/issues/450)
• https://github.com/knative/serving/issues/14216
• https://github.com/knative/serving/issues/14217
• https://github.com/knative/serving/issues/13820
• https://github.com/knative/serving/issues/14218
• https://github.com/knative/serving/issues/13819
• Add documentation
• Add to release notes

Beta (enabled by default, can be deactivated)

• Implement the configuration to fully disable the http listeners in all components (https://github.com/knative/serving/issues/12808 as well as https://github.com/knative/serving/issues/12821)
• Change the flag to be enabled by default

GA (enabled by default, can be deactivated)

• We probably want users to still be able to disabled internal-encryption in GA, right?
• Anything else to do, coming from beta?

Implement the configuration to fully disable the http listeners in all components

If you like, you can link to the following issues.

• https://github.com/knative/serving/issues/12821
• https://github.com/knative/serving/issues/12808

#12808 is simple but I guess #12821 is not simple so we can handle #12821 as another issue. Sounds good to me other than that.

Related: https://github.com/knative/serving/issues/13472

After an additional review of the status, we identified a series of gaps that we now aim to close.

• [x] https://github.com/knative/serving/issues/13764
• [x] https://github.com/knative-sandbox/control-protocol/issues/264
• [x] https://github.com/knative/pkg/issues/2699
• [x] https://github.com/knative/networking/issues/777

We have established the necessary infrastructure for adding support for a number of trust options:

• dataplane-trust = "minimal" ensures data messages are encrypted, Kingress authenticate that the receiver is a Ksvc
• dataplane-trust = "enabled" same as "minimal" and in addition, Kingress authenticate that Ksvc is at the correct namespace
• dataplane-trust = "mutual" same as "enabled" and in addition, Ksvc authenticate that the messages come from the Kingress

we also have a future-looking option:

• dataplane-trust = "identity" same as "mutual" with Kingress adding a trusted sender identity to the message

We now start the journey to add support for these options in all data elements of the system. Apparently we will need to modify:

• [ ] Queue
• [ ] Activator
• [ ] Kourier
• [ ] Contour
• [ ] Istio
• [ ] GW API