Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

All hops encrypted amongst internal and external services in Knative #11906

Open
5 of 6 tasks
nainaz opened this issue Sep 3, 2021 · 16 comments
Open
5 of 6 tasks

All hops encrypted amongst internal and external services in Knative #11906

nainaz opened this issue Sep 3, 2021 · 16 comments
Labels
kind/feature Well-understood/specified features, ready for coding. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Issues which should be fixed (post-triage)
Projects
Security WG Roadmap

Comments

@nainaz
Copy link

nainaz commented Sep 3, 2021 •
edited by evankanderson
Loading

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:
@nainaz nainaz added the kind/feature Well-understood/specified features, ready for coding. label Sep 3, 2021
@nainaz
Copy link
Author

nainaz commented Sep 3, 2021 •
edited
Loading

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

@n3wscott
Copy link
Contributor

n3wscott commented Sep 3, 2021

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

@antoineco
Copy link
Contributor

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.

@nainaz
Copy link
Author

nainaz commented Sep 9, 2021 via email

@nainaz
Copy link
Author

nainaz commented Sep 15, 2021 via email

@evankanderson evankanderson added this to In Progress in Security WG Roadmap via automation Sep 21, 2021
@evankanderson evankanderson mentioned this issue Sep 21, 2021
Closed
@evankanderson
Copy link
Member

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

@github-actions
Copy link

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.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 21, 2021
@nak3 nak3 added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Dec 21, 2021
@evankanderson
Copy link
Member

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.

@nak3
Copy link
Contributor

nak3 commented Jan 13, 2022 •
edited
Loading

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 kubernetes-sigs/gateway-api#968

nak3 added a commit to nak3/serving that referenced this issue Mar 28, 2022
@nak3
Force activator always in path when activator CA is specified
fca1a70 
As described in the feature doc of knative#11906,
activator needs to serve TLS traffic for the traffic from ingress.

So, this patch force SKS proxy mode when `activator-ca` in
`config-network` is specified.
@nak3 nak3 mentioned this issue Mar 28, 2022
Merged
nak3 added a commit to nak3/serving that referenced this issue Mar 28, 2022
@nak3
Force activator always in path when activator CA is specified
1d5f022 
As described in the feature doc of knative#11906,
activator needs to serve TLS traffic for the traffic from ingress.

So, this patch force SKS proxy mode when `activator-ca` in
`config-network` is specified.
nak3 added a commit to nak3/serving that referenced this issue Mar 28, 2022
@nak3
Force activator always in path when activator CA is specified
15845a5 
As described in the feature doc of knative#11906,
activator needs to serve TLS traffic for the traffic from ingress.

So, this patch force SKS proxy mode when `activator-ca` in
`config-network` is specified.
knative-prow bot pushed a commit that referenced this issue Apr 2, 2022
@nak3
Force activator always in path when activator CA is specified (#12790)
21c05dc 
* Force activator always in path when activator CA is specified

As described in the feature doc of #11906,
activator needs to serve TLS traffic for the traffic from ingress.

So, this patch force SKS proxy mode when `activator-ca` in
`config-network` is specified.

* Fix typo

* Use switch
@nak3 nak3 mentioned this issue Apr 13, 2022
Merged
@arturdzm arturdzm mentioned this issue Jun 2, 2022
Closed
@nak3 nak3 mentioned this issue Jun 16, 2022
Closed
@ReToCode
Copy link
Member

  • 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

@evankanderson
Copy link
Member

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.

@ReToCode ReToCode mentioned this issue Jan 31, 2023
Merged
@ReToCode
Copy link
Member

ReToCode commented Feb 3, 2023 •
edited
Loading

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

Alpha (disabled by default)

Beta (enabled by default, can be deactivated)

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?

@nak3
Copy link
Contributor

nak3 commented Feb 6, 2023

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

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

#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.

@ReToCode
Copy link
Member

Related: #13472

@ReToCode ReToCode mentioned this issue Feb 14, 2023
Closed
This was referenced Feb 16, 2023
Closed
Open
@ReToCode ReToCode mentioned this issue Feb 28, 2023
Open
@davidhadas
Copy link
Contributor

davidhadas commented Mar 5, 2023 •
edited
Loading

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

@ReToCode ReToCode added the triage/accepted Issues which should be fixed (post-triage) label Mar 8, 2023
@ReToCode ReToCode mentioned this issue Mar 29, 2023
Open
4 tasks
@KauzClay KauzClay mentioned this issue Apr 6, 2023
Open
@davidhadas
Copy link
Contributor

davidhadas commented May 9, 2023 •
edited
Loading

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

This was referenced May 9, 2023
Closed
Closed
@nak3 nak3 mentioned this issue Jun 16, 2023
Merged
@ReToCode ReToCode mentioned this issue Aug 2, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature Well-understood/specified features, ready for coding. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Issues which should be fixed (post-triage)
Projects
Security WG Roadmap
Status: Icebox
Serving Encryption
Status: No status
Security WG Roadmap
In Progress
Milestone
No milestone
Development

No branches or pull requests
7 participants
@nak3 @antoineco @davidhadas @evankanderson @ReToCode @n3wscott @nainaz