Cloud-native high-performance edge/middle/service proxy

Overview

Envoy Logo

Cloud-native high-performance edge/middle/service proxy

Envoy is hosted by the Cloud Native Computing Foundation (CNCF). If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Envoy plays a role, read the CNCF announcement.

CII Best Practices Azure Pipelines Fuzzing Status Jenkins

Documentation

Related

Contact

  • envoy-announce: Low frequency mailing list where we will email announcements only.
  • envoy-security-announce: Low frequency mailing list where we will email security related announcements only.
  • envoy-users: General user discussion.
  • envoy-dev: Envoy developer discussion (APIs, feature design, etc.).
  • envoy-maintainers: Use this list to reach all core Envoy maintainers.
  • Twitter: Follow along on Twitter!
  • Slack: Slack, to get invited go here. We have the IRC/XMPP gateways enabled if you prefer either of those. Once an account is created, connection instructions for IRC/XMPP can be found here.
    • NOTE: Response to user questions is best effort on Slack. For a "guaranteed" response please email [email protected] per the guidance in the following linked thread.

Please see this email thread for information on email list usage.

Contributing

Contributing to Envoy is fun and modern C++ is a lot less scary than you might think if you don't have prior experience. To get started:

Community Meeting

The Envoy team meets twice per month on Tuesday at 9am PT. The public Google calendar is here: https://goo.gl/PkDijT

  • Meeting minutes are here
  • Recorded videos are posted here

Security

Security Audit

There has been several third party engagements focused on Envoy security:

  • In 2018 Cure53 performed a security audit, full report.
  • In 2021 Ada Logics performed an audit on our fuzzing infrastructure with recommendations for improvements, full report.

Reporting security vulnerabilities

If you've found a vulnerability or a potential vulnerability in Envoy please let us know at envoy-security. We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issue positively or negatively.

For further details please see our complete security release process.

Issues
  • [TESTING] repokitteh - please ignore

    [TESTING] repokitteh - please ignore

    Signed-off-by: Ryan Northey [email protected]

    For an explanation of how to fill out the fields, please see the relevant section in PULL_REQUESTS.md

    Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Deprecated:]

    stale rk:blessed 
    opened by phlax 181
  • listener: remove the peek from the listener filters

    listener: remove the peek from the listener filters

    Commit Message: listener: remove the peek from the listener filters Additional Description: To avoid the listener filters to peek the data from the socket directly, allow the ActiveTcpSocket to peek the data into the buffer. The ActiveTcpSocket will get the max data expected from the filters through the filter interface size_t maxReadBytes(). Then ActiveTcpSocket will listen on the file event on the socket. And peek the data into the buffer. And calling the listener filter callback onData(Buffer::Instance&).

    If the filter doesn't need any data from the connection, it should return 0 on the interface 'maxReadBytes()'. The ActiveTcpSocket won't listen on the file event if there is no filter expecting any data.

    The buffer will be shared across the listener filter. no duplicated peek need anymore.

    The buffer is implemented by ListenerFilterBufferImpl. It will store the data peeked from the socket, and provide the const pointer to the listener filter to access the data. It also provides the interface for listener filter to drain the data, and the data will be drained on the socket in the end.

    Risk Level: high Testing: unit tests and integration tests Docs Changes: add document for the new stats Release Notes: add release note for new stats Fixes: #17229

    Signed-off-by: He Jie Xu [email protected]

    api v2-freeze 
    opened by soulxu 121
  • Provide an official ARM docker image and/or provide documentation for building on ARM

    Provide an official ARM docker image and/or provide documentation for building on ARM

    Would it be possible to get an official Docker image of Envoy on ARM or at least some documentation on how to build it? My team and I have tried off and on to build Envoy on ARM using the Bazel build process without any luck. Its challenging to say the least. I just saw a PR #1795 by @costinm dated a couple weeks ago based on the issue #1781 that talked about building it on ARM successfully after a few fixes. This is great news but we aren't sure how to duplicate it. @costinm mentioned that he used a custom CMAKE and a pi-cross-compiler to make it work. Documentation on this would be very helpful. Also, if there exist an image I could use for testing, then that would be very helpful too. Thanks again for such an awesome product!

    area/build help wanted 
    opened by gizmochief7 97
  • TLS key log feature

    TLS key log feature

    Now more and more traffic will use TLS to encrypt the traffic for security consideration. When there are some network issues, we always use tcpdump tool to capture the packets to analyze the first hand traffic data to find the root cause. Although there are some logs, the first hand data (packets) is the most reliable one.

    v2-freeze 
    opened by zhangbo1882 94
  • Refactoring Envoy DNS resolution as extension

    Refactoring Envoy DNS resolution as extension

    Problem Description: This PR is the code changes for refactoring Envoy DNS resolution as first class extension for issue: #14310. This is a follow up PR of #17272.

    Solution: 1 Move c-ares and Apple DNS resolvers to their own extensions. 2) Create a DnsResolver factory interface, and derive two sub factory classes from it: CaresDnsResolver and AppleDnsResolver, each implement the method to create the corresponding dns_resolver object. 3) Refactor the boostrap_, cluster, dns_cache and dns_filter configuration parsing code, removing the dns_resolution_config parsing logic from them, call a standalone template function to parse the configuration, get a typed configuration. In this, 2.1) if theTypedExtensionConfig is in the config, using it to get the corresponding factory. 2.2) if TypedExtensionConfig is missing, then : if this is MacOS, and the run time flag: envoy.restart_features.use_apple_api_for_dns_lookups is enabled, then have the Envoy config factory synthesize a apple DNS resolver TypedExtensionConfig, and using it to get the apple DNS resolver factory. In all other cases, have the Envoy Synthesize a pseudo-configuration for the c-ares TypedExtensionConfig, and using it to get the cares DNS resolver factory 4) The DNS resolver factory retrieved in 3) will create a corresponding DNS resolver object (cares or apple).

    Build: passed

    Testing: passed

    Release Notes: N/A

    Issues: DNS resolver as an extension point #14310

    Fix #14310

    Signed-off-by: Yanjun Xiang [email protected]

    Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Deprecated:] [Optional API Considerations:]

    opened by yanjunxiang-google 88
  • filters: add generic compressor filter

    filters: add generic compressor filter

    Description:

    Add generic compressor_lib which can be reused by all HTTP compression filters to

    1. parse Accepted-Encoding;
    2. update HTTP headers;
    3. decide which encoding to use for compression in case there are more than one compression filters in the same chain.

    Risk Level: High Testing: unit tests, manual tests Docs Changes: N/A Release Notes: N/A

    Contributes to #4429

    Design doc: Envoy HTTP Filters: Generic Compressor and Decompressor

    opened by rojkov 82
  • stats: native prometheus export support

    stats: native prometheus export support

    Things that need sorting out:

    • [x] Push vs. pull
    • [ ] If we do native pull, Envoy will need a built-in histogram implementation. We need this for outlier detection also. The implementation I was planning on using is an HDR histogram implemented here: https://github.com/circonus-labs/libcircllhist (https://github.com/envoyproxy/envoy/issues/1965)
    enhancement help wanted 
    opened by mattklein123 71
  • dist: Add debian packaging

    dist: Add debian packaging

    Commit Message: dist: Add debian packaging Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Deprecated:] [Optional API Considerations:]

    deps 
    opened by phlax 70
  • filter: add conditions to access control filter

    filter: add conditions to access control filter

    Signed-off-by: Kuat Yessenov [email protected]

    Introduces a generic expression-based admission filter using https://github.com/google/cel-cpp. This is a follow-up to discussion in https://github.com/envoyproxy/envoy/issues/6751. The advantage of this approach is:

    1. Un-opinionated about the policy structure since the only config is an expression. This is friendly towards control planes which can bear the complexity of translation, analysis, and evolution of policies.
    2. Multi-language, CEL supports go, java, and c++ runtimes.
    3. Inter-operability with other filters using request metadata. Companion filters can populate metadata about requests and resources that affect policy decisions.
    4. Generic utility, it can be used for custom metric labels, access log entries, etc.

    The dis-advantage of this approach is that its performance is lower than domain-optimized interpreters. On a fair example, the interpreter evaluates in around 1ms (see https://github.com/google/cel-cpp/blob/master/eval/tests/benchmark_test.cc#L591) vs ~150ns for hand-written C++ native code. There is space for improvement (especially if WASM can be used as a compilation target), but ultimately the generic expression form carries a cost.

    Conditions are added to support RBAC filter for complementing the existing principal/permission model. They add support for the extended checks (e.g. time of query, resource-bound), but add no cost unless used.

    Description: add expression-based admission filter Risk Level: low Testing: Docs Changes: Release Notes:

    opened by kyessenov 68
  • UDP proxying support

    UDP proxying support

    Edit: (@alyssawilk on behalf of @cmluciano)

    Design doc:

    https://docs.google.com/document/d/1G9IVq7F7Onwinsl6EYzGsdzAGvVbo2FGfcPt35ItIx8)

    Roadmap

    • [ ] General API refactoring (Ex. less file-descriptor hardcoding)
    • [ ] UDP listener
    • [ ] UDP "session manager"
    • [ ] Basic UDP proxying sessions (proxy -> host)
    • [ ] Advanced UDP proxying features (timeouts, filters, etc.)
    • [ ] Network filters (need a use-case)
    • [ ] Clear documentation with configuration and developer walkthroughs of UDP features

    Original top level comment (@rshriram)

    Just like TCP proxying, it would be great if Envoy had support UDP proxying as well.

    The current code for TCP proxying is pretty generic for most part. The flow is something like this: on_connection_received_callback() -->pick upstream and connect to it on_data_received_callback(data) -->write_to_upstream(data) on_stream_reset_callback() [downstream reset or upstream reset?] -->cleanups Based on a cursory scan through the code, there is also a timer that cleans up connections beyond a certain period of inactivity ( @mattklein123 please confirm).

    In terms of UDP support, much of the code in filters above can be repurposed or renamed to be generic to TCP/UDP where possible.

    The ClientConnectionImpl class hardcodes the socket type to be Stream. This needs to be changed.

    UDP packets with source port 0 should be dropped(?)

    Instead of creating/destroying UDP connection objects per packet, the process can be optimized by having a keepalive style timer that deletes the connection objects after timer expiry. UDP datagram size can be fixed to one MTU or less, as a first order approximation, that should (RFC 791, RFC 2460). We do not need to buffer up data and send it out. WDYT?

    In terms of session affinity, packets from same src port, src ip would go to same dst port, dst ip.

    enhancement no stalebot area/quic 
    opened by rshriram 68
  • minor perf: reduce fine grained buffer access when encoding HTTP1 headers

    minor perf: reduce fine grained buffer access when encoding HTTP1 headers

    Commit Message: minor perf: reduce fine grained buffer access when encoding HTTP1 headers

    Additional Description:

    The HTTP1 codec performs a large number of buffer APIs calls during the encoding of HTTP headers, which introduces an additional CPU overhead (3-4%). This PR implements a buffer helper as a cache to reduce direct buffer writes to improving the overall performance.

    Check this https://github.com/envoyproxy/envoy/issues/19103#issuecomment-980519299 for some more related info.

    This PR reverts #9825. At the same time, I also try my best to make the code simpler and easier to maintain.

    Risk Level: High. Testing: Waiting. Docs Changes: N/A. Release Notes: N/A.

    Some benchmark results:

    The total amount of data written in each test is the same, 64MB. The figure shows the performance of using different APIs and different basic write unit sizes.

    In addFrags/{n}, n represents the number of units written by the addFragments API in batches. For example, when the write unit is 16 bytes, addFrags/3 means to use addFragments to write 3 strings of 16 bytes at one time.

    Y-axis: number of nanoseconds to complete 64mb data writes. Higher Y-axis is slower. X-axis: basic write unit bytes size. add can only writes one basic unit one time and addFragments can writes multiple units one time.

    image

    image

    From the graph, addFrags/5 gives the best performance in most all cases.

    opened by wbpcode 67
  • config-plane: refactor resource decoder to be a shared pointer

    config-plane: refactor resource decoder to be a shared pointer

    Commit Message: refactor resource decoder to be a shared pointer Additional Description: Prior to this PR the OpaqueResourceDecoder was owned by each of the Subscriptions, and a reference to it was used by the GrpcMux's. This can cause an issue if the Mux outlives the subscription, as can happen in the newly added test ValidResourceDecoderAfterRemoval, and in the unified Mux implementation. This PR converts the OpaqueResourceDecoder to a shared pointer, that can be used by both.

    Risk Level: Low/Medium - modifying many places in the config-plane codebase, but the refactor switches from a reference to a shared pointer. Testing: Added a unit test that fails if non-shared pointer is used. Docs Changes: N/A. Release Notes: TBD. Platform Specific Features: N/A

    Signed-off-by: Adi Suissa-Peleg [email protected]

    opened by adisuissa 1
  • grpc: depicted wire format corrected

    grpc: depicted wire format corrected

    Signed-off-by: Amila Senadheera [email protected]

    Commit Message: grpc: depicted wire format corrected

    Additional Description: Compressed-Flag of the grpc data frame header is 1 byte in size but it was depicted using 9 bits with an additional reserved bit and it was corrected. Reference - https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md

    Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional API Considerations:]

    opened by Amila-Rukshan 0
  • Draft: tracing: dubbo proxy tracing #17601

    Draft: tracing: dubbo proxy tracing #17601

    This is my first PR for envoy. I'm worried about whether I'm dealing with this issue #17601 in a complete wrong way. So, currently even I'm not finished, I'm opening this PR for review purpose. It built, and ran. Didn't make service call to step in the tracing logic. I will do this the next step, to debug through, to make sure this PR works.

    I found it's looks not possible to implement tracing in a isolate filter without a large scale refactor, neither the http_connection_manger nor the router filter of dubbo_proxy do. The dubbo router still coupling with dubbo's connection manager and active message.

    Meanwhile, Http::createHeaderMap<Http::RequestHeaderMapImpl>(invocation_impl->attachment().headers()); should not work, mainly because dubbo's attachment dosen't have keys like authority or method. It's need some extra logic to reuse http's tracing classes and methods. Also the occasion of span manipulations may need to adjust.

    Commit Message: Add tracing support for dubbo proxy Additional Description: #17601 Risk Level: Low Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional API Considerations:]

    opened by tedli 1
  • ratelimit: support response_headers_to_add

    ratelimit: support response_headers_to_add

    Commit Message: ratelimit: support response_headers_to_add Additional Description: ratelimit support response_headers_to_add like local_ratelimit Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional API Considerations:]

    api 
    opened by zirain 1
  • question regarding websocket proxying

    question regarding websocket proxying

    my backend support only websocket with binary data,

    can envoy accept websocket connection accept text mode from downstream and convert to binary when talking to upstream ?

    something like

    --- ----

    Thank you

    triage 
    opened by SunChero 0
  • unexpected stats behavior

    unexpected stats behavior

    Istio use "regex": "(response_code=\\.=(.+?);\\.;)|_rq(_(\\.d{3}))$" for response_code stats tag, here is the source code.

    I test with the following stats, which work as expected:

    stats_config:
      use_all_default_tags: false
      stats_tags:
        - tag_name: response_code
          regex: "_rq(_(\\d{3}))$"
          #regex: "(response_code=\\.=(.+?);\\.;)|_rq(_(\\d{3}))$"
          #regex: "_rq(_(\\d{3}))$|(response_code=\\.=(.+?);\\.;)"
    admin:
      access_log_path: /tmp/admin_access.log
      address:
        socket_address:
          protocol: TCP
          address: 127.0.0.1
          port_value: 9901
    static_resources:
      listeners:
        - name: listener_0
          address:
            socket_address:
              protocol: TCP
              address: 0.0.0.0
              port_value: 10000
          filter_chains:
            - filters:
                - name: envoy.filters.network.http_connection_manager
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                    stat_prefix: ingress_http
                    codec_type: auto
                    route_config:
                      name: local_route
                      virtual_hosts:
                        - name: local_service
                          domains:
                            - "*"
                          routes:
                            - match:
                                prefix: "/"
                              route:
                                cluster: default_service
                    http_filters:
                      - name: envoy.filters.http.router
                        typed_config:
                          "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
    
        - name: staticreply-8080
          address:
            socket_address:
              address: 127.0.0.1
              port_value: 8080
          filter_chains:
            - filters:
                - name: envoy.http_connection_manager
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                    stat_prefix: ingress_http
                    codec_type: auto
                    route_config:
                      name: local_route
                      virtual_hosts:
                        - name: local_service
                          domains:
                            - "*"
                          routes:
                            - match:
                                prefix: "/"
                              direct_response:
                                status: 200
                                body:
                                  inline_string: "example body\n"
                    http_filters:
                      - name: envoy.filters.http.router
                        typed_config:
                          "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
    
      clusters:
        - name: default_service
          load_assignment:
            cluster_name: default_service
            endpoints:
              - lb_endpoints:
                  - endpoint:
                      address:
                        socket_address:
                          address: 127.0.0.1
                          port_value: 8080
    

    but when I change regex string to "(response_code=\\.=(.+?);\\.;)|_rq(_(\\d{3}))$" , I only get output with following:

    $ curl 127.0.0.1:10000 && curl 127.0.0.1:9901/stats/prometheus | grep response_code
    envoy_cluster_default_service_external_upstream_rq_200{response_code=""} 2
    envoy_cluster_default_service_upstream_rq_200{response_code=""} 2
    

    then I change regex string to "_rq(_(\\d{3}))$|(response_code=\\.=(.+?);\\.;)", the output looks good again:

    envoy_cluster_default_service_external_upstream_rq{response_code="200"} 1
    envoy_cluster_default_service_upstream_rq{response_code="200"} 1
    

    Anyone what's the root cause?

    triage 
    opened by zirain 0
Releases(v1.22.4)
Owner
Envoy Proxy - CNCF
Envoy Proxy - CNCF
Envoy Proxy - CNCF
Cloud Native Data Plane (CNDP) is a collection of user space libraries to accelerate packet processing for cloud applications.

CNDP - Cloud Native Data Plane Overview Cloud Native Data Plane (CNDP) is a collection of userspace libraries for accelerating packet processing for c

Cloud Native Data Plane 22 Jul 27, 2022
An eventing framework for building high performance and high scalability systems in C.

NOTE: THIS PROJECT HAS BEEN DEPRECATED AND IS NO LONGER ACTIVELY MAINTAINED As of 2019-03-08, this project will no longer be maintained and will be ar

Meta Archive 1.7k Jul 28, 2022
Plays native alert sound and shows native dialogs/alerts in your Flutter app.

flutter_platform_alert 2021 © Weizhong Yang a.k.a zonble. A simple plugin to present native alerts, including playing alert sounds and showing alert d

Weizhong Yang a.k.a zonble 55 Jul 23, 2022
Visual Studio native debugger extension to help debug native applications using Mono.

Unity Mixed Callstack UnityMixedCallstack is a Visual Studio 2017/2019 extension to help debug native applications embedding Mono, like Unity. If you

Unity Technologies 73 Aug 5, 2022
EdgeTX is the cutting edge of OpenTx

Welcome to EdgeTX! The cutting edge open-source firmware for your R/C radio! About EdgeTX EdgeTX is the cutting edge of OpenTX. It is the place where

null 687 Aug 6, 2022
ESP32 + Arducam Mini 2MP Plus Edge Impulse Example

Minimal example code for running an Edge Impulse image classification network with the ESP32, ArduCAM, and PlatformIO

David Schwarz 6 Apr 23, 2022
JavaScript runtime for Fastly [email protected]

Fastly [email protected] JS Runtime The JS Compute Runtime for Fastly's [email protected] platform provides the environment JavaScript is executed in when using

Fastly 83 Aug 3, 2022
code for the Proxy DLL example blog post

ProxyDLLExample A simple DLL for Windows that can be used to demonstrate a DLL Proxy Attack. This project uses GCC through MinGW was tested on Ubuntu

Cobalt Strike 45 Jul 12, 2022
Qnicorn: a cutting edge version of unicorn-engine.org

Qnicorn Engine Qnicorn is a cutting edge and community-driven version of unicorn-engine. Qnicorn offers the features below: All features that Unicorn2

qiling.io 2 Mar 2, 2022
Semantic Edge Detection with Diverse Deep Supervision

Semantic Edge Detection with Diverse Deep Supervision This repository contains the code for our IJCV paper: "Semantic Edge Detection with Diverse Deep

Yun Liu 11 May 15, 2022
PoC of Swift for [email protected]

FastlyEdgeExample An example project to deploy Swift code to Fastly's [email protected] Requirements SwiftWasm toolchain fastly CLI How to deploy $ fastly

Yuta Saito 11 May 21, 2022
An example of COM hijacking using a proxy DLL.

COM-Hijacking An example of COM hijacking using a proxy DLL. Demo using getmac/wbemprox.dll In this demo, we use the fact that the getmac.exe command

Solomon Sklash 13 Jun 4, 2022
Ccd - Edge first cd replacement tool for Windows cmd shell.

Cursorial CD Cursorial CD, or ccd for short, is a cd replacement for Window's cmd shell. Unlike cd, it operates on an edge first search, so you can qu

Scott Seligman 5 Feb 2, 2022
An all-in-one Spartan Edge Accelerator shield implementation for the gbaHD

gbaHD AIO Shield This is a Spartan Edge Accelerator shield which implements all the hardware connections needed for zwenergy's gbaHD, no wires require

null 36 Jul 10, 2022
BOF implementation of chlonium tool to dump Chrome/Edge Masterkey

ChromiumKeyDump BOF implementation of Chlonium tool to dump Chrome/Edge Masterkey. Forked from https://github.com/crypt0p3g/bof-collection Setup How t

null 2 Feb 12, 2022
A USB proxy based on raw-gadget and libusb

usb-proxy This software is a USB proxy based on raw-gadget and libusb. It is recommended to run this repo on a computer that has an USB OTG port, such

Aristo Chen 25 Jul 27, 2022
New lateral movement technique by abusing Windows Perception Simulation Service to achieve DLL hijacking code execution.

BOF - Lateral movement technique by abusing Windows Perception Simulation Service to achieve DLL hijacking ServiceMove is a POC code for an interestin

Chris Au 174 Jul 10, 2022
This is Script tools from all attack Denial of service by C programming

RemaxDos Paltfrom Attack RemaxDos This is Script tools from all attack Denial of service Remax Box Team !. Features ! Cam overflow Syn Flooding. Smurf

null 6 Jul 19, 2022
Basic Windows Service managment API

SvcManager Basic Windows Service managment API A simple C++ Windows Service management API built my me. To be honest, I havent committed anything in a

Josh S. 3 Feb 13, 2022