EXTENSION_POLICY.md

Envoy Extension Policy

Quality requirements

All extensions contained in the main Envoy repository will be held to the same quality bar as the core Envoy code. This includes coding style, code reviews, test coverage, etc. In the future we may consider creating a sandbox repository for extensions that are not compiled/tested by default and held to a lower quality standard, but that is out of scope currently.

Adding new extensions

The following procedure will be used when proposing new extensions for inclusion in the repository:

1. A GitHub issue should be opened describing the proposed extension as with any major feature proposal.

2. All extensions must be sponsored by an existing maintainer. Sponsorship means that the maintainer will shepherd the extension through design/code reviews. Maintainers can self-sponsor extensions if they are going to write them, shepherd them, and maintain them.

   Sponsorship serves two purposes:

   • It ensures that the extension will ultimately meet the Envoy quality bar.
   • It makes sure that incentives are aligned and that extensions are not added to the repo without sufficient thought put into future maintenance.

   If sponsorship cannot be found from an existing maintainer, an organization can consider doing the work to become a maintainer in order to be able to self-sponsor extensions.

3. Each extension must have two reviewers proposed for reviewing PRs to the extension. Neither of the reviewers must be a senior maintainer. Existing maintainers (including the sponsor) and other contributors can count towards this number. The initial reviewers will be codified in the CODEOWNERS file for long term maintenance. These reviewers can be swapped out as needed.

4. Any extension added via this process becomes a full part of the repository. This means that any API breaking changes in the core code will be automatically fixed as part of the normal PR process by other contributors.

5. Any new dependencies added for this extension must comply with DEPENDENCY_POLICY.md, please follow the steps detailed there.

Removing existing extensions

As stated in the previous section, once an extension becomes part of the repository it will be maintained by the collective set of Envoy contributors as needed.

However, if an extension has known issues that are not being rectified by the original sponsor and reviewers or new contributors that are willing to step into the role of extension owner, a vote of the maintainers can be called to remove the extension from the repository.

Extension pull request reviews

Extension PRs must not modify core Envoy code. In the event that an extension requires changes to core Envoy code, those changes should be submitted as a separate PR and will undergo the normal code review process, as documented in the contributor's guide.

Extension PRs must be approved by at least one sponsoring maintainer and an extension reviewer. These may be a single individual, but it is always preferred to have multiple reviewers when feasible.

In the event that the Extension PR author is a sponsoring maintainer and no other sponsoring maintainer is available, another maintainer may be enlisted to perform a minimal review for style and common C++ anti-patterns. The Extension PR must still be approved by a non-maintainer reviewer.

Extension stability and security posture

Every extension is expected to be tagged with a status and security_posture in its envoy_cc_extension rule.

The status is one of:

• stable: The extension is stable and is expected to be production usable. This is the default if no status is specified.
• alpha: The extension is functional but has not had substantial production burn time, use only with this caveat.
• wip: The extension is work-in-progress. Functionality is incomplete and it is not intended for production use.

The extension status may be adjusted by the extension CODEOWNERS and/or Envoy maintainers based on an assessment of the above criteria. Note that the status of the extension reflects the implementation status. It is orthogonal to the API stability, for example, an extension with configuration envoy.foo.v3alpha.Bar might have a stable implementation and envoy.foo.v3.Baz can have a wip implementation.

The security_posture is one of:

• robust_to_untrusted_downstream: The extension is hardened against untrusted downstream traffic. It assumes that the upstream is trusted.
• robust_to_untrusted_downstream_and_upstream: The extension is hardened against both untrusted downstream and upstream traffic.
• requires_trusted_downstream_and_upstream: The extension is not hardened and should only be used in deployments where both the downstream and upstream are trusted.
• unknown: This is functionally equivalent to requires_trusted_downstream_and_upstream, but acts as a placeholder to allow us to identify extensions that need classifying.
• data_plane_agnostic: Not relevant to data plane threats, e.g. stats sinks.

An assessment of a robust security posture for an extension is subject to the following guidelines:

• Does the extension have fuzz coverage? If it's only receiving fuzzing courtesy of the generic listener/network/HTTP filter fuzzers, does it have a dedicated fuzzer for any parts of the code that would benefit?
• Does the extension have unbounded internal buffering? Does it participate in flow control via watermarking as needed?
• Does the extension have at least one deployment with live untrusted traffic for a period of time, N months?
• Does the extension rely on dependencies that meet our extension maturity model?
• Is the extension reasonable to audit by Envoy security team?
• Is the extension free of obvious scary things, e.g. memcpy, does it have gnarly parsing code, etc?
• Does the extension have active CODEOWNERS who are willing to vouch for the robustness of the extension?
• Is the extension absent a low coverage exception?

The current stability and security posture of all extensions can be seen here.