Skip to content

Secure Application to Application Traffic #1537

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.

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

Open
3 tasks
mpstefan opened this issue Feb 2, 2024 · 1 comment
Open
3 tasks

Secure Application to Application Traffic #1537

mpstefan opened this issue Feb 2, 2024 · 1 comment
Labels
epic Represents an epic. Contains sub-issues
Milestone

Comments

@mpstefan
Copy link
Member

mpstefan commented Feb 2, 2024

As a user of NGF who requires application to application traffic within their cluster
I want NGF to secure my application to application traffic with mTLS
So that all my traffic is encrypted during transit within the cluster
And so that all origins of application to application traffic within the cluster are verified.

Background

Part of the promise of NGINX Gateway Fabric is to handle both North/South use cases in addition to select East/West use cases. The most common use case for East/West traffic management is to secure all application to application traffic within the cluster. As such, this will be the first East/West traffic capability we should add.

As part of this epic, we need to consider a few things:

  • There is a perception that sidecars often cause too large of an overhead of CPU/Memory
  • We need to avoid the perception that we are "too heavy" beyond overhead.
    • For instance, imposing too many requirements as to how applications can talk to each other. We should aim to be as "modular" as possible.
  • Ensure compatibility with service meshes should the use wish to use us strictly for North/South traffic.
    • We have evidence that users will be looking for a "lighter" service mesh like solution, but in the case they need more functionality from a full service mesh, we need to maintain compatibility. Likely through a enable/disable mechanism.
  • We will very likely include Egress controls in a later release.

Acceptance Criteria

  • All applications within the scope of NGF communicate with mTLS without any code changes required of the applications.

Tasks

For Discussion

  • Are there any sidecar-less solutions we can investigate?
  • What architecture pattern do we want to pursue?
    • Use code from NSM to create minimal sidecar?
    • Hairclip; Sidecar to Gateway pod to destination pod
    • VPN to other pods
    • DNS to hijack connections to go to gateway, then gateway does encryption
      • Likely not enforceable with IPs
  • What should the design encapsulate? Do we need any additional spikes or prototypes?
@mpstefan mpstefan added the epic Represents an epic. Contains sub-issues label Feb 2, 2024
@mpstefan mpstefan added this to the v2.1.0 milestone Feb 2, 2024
@mpstefan mpstefan modified the milestones: v2.0.0, v2.1.0 Apr 11, 2024
@mpstefan mpstefan modified the milestones: v2.0.0, v2.1.0 Jun 12, 2024
@laurentpf5
Copy link

Totally agree that our customers are looking for something wich is preferably sidecar less but gives encryption for service to service communitation and visibility.

@mpstefan mpstefan modified the milestones: v2.1.0, v2.2.0 Jul 26, 2024
@mpstefan mpstefan modified the milestones: v2.1.0, v2.2.0 Aug 7, 2024
@mpstefan mpstefan modified the milestones: v2.2.0, v2.1.0 Oct 28, 2024
@mpstefan mpstefan modified the milestones: v2.1.0, v2.2.0 Dec 16, 2024
@mpstefan mpstefan modified the milestones: v2.2.0, v2.3.0, v2.4.0 Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Represents an epic. Contains sub-issues
Projects
Status: 🆕 New
Development

No branches or pull requests

2 participants