Skip to content

Secure Application to Application Traffic #1537

Open
@mpstefan

Description

@mpstefan

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicRepresents an epic. Contains sub-issues

    Type

    No type

    Projects

    Status

    🆕 New

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions