Merge remote envoy

.circleci/config.yml

@@ -62,7 +62,7 @@ jobs:
      steps:
        - run: rm -rf /home/circleci/project/.git # CircleCI git caching is likely broken
        - checkout
-       - run: pip install -r tools/requirements.txt
+       - run: pip install -r tools/code_format/requirements.txt
        - run: ci/do_circle_ci.sh check_format
        - run: ci/do_circle_ci.sh check_repositories
        - run: ci/do_circle_ci.sh check_spelling

.gitignore

@@ -24,7 +24,7 @@ SOURCE_VERSION
 tags
 TAGS
 /test/coverage/BUILD
-/tools/.aspell.en.pws
+/tools/spelling/.aspell.en.pws
 .vimrc
 .vs
 .vscode

CODEOWNERS

@@ -53,7 +53,7 @@ extensions/filters/common/original_src @snowp @klarose
 /*/extensions/filters/http/cache @toddmgreer @jmarantz
 # aws_iam grpc credentials
 /*/extensions/grpc_credentials/aws_iam @lavignes @mattklein123
-/*/extensions/filters/http/common/aws @lavignes @mattklein123
+/*/extensions/common/aws @lavignes @mattklein123
 # adaptive concurrency limit extension.
 /*/extensions/filters/http/adaptive_concurrency @tonya11en @mattklein123
 # http inspector

CONTRIBUTING.md

@@ -69,18 +69,6 @@ versioning guidelines:
   it is expected the multi-phase warn-by-default/fail-by-default is sufficient to warn users to move
   away from deprecated features.
 
-# Release cadence
-
-* Currently we are targeting approximately quarterly official releases. We may change this based
-  on customer demand.
-* In general, master is assumed to be release candidate quality at all times for documented
-  features. For undocumented or clearly under development features, use caution or ask about
-  current status when running master. Lyft runs master in production, typically deploying every
-  few days.
-* Note that we currently do not provide binary packages (RPM, etc.). Organizations are expected to
-  build Envoy from source. This may change in the future if we get resources for maintaining
-  packages.
-
 # Submitting a PR
 
 * Fork the repo.

GOVERNANCE.md

@@ -70,16 +70,15 @@ or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/get
 
 ## Cutting a release
 
-* We do releases approximately every 3 months as described in the
-  [release cadence documentation](CONTRIBUTING.md#release-cadence).
-* Decide on the somewhat arbitrary time that a release will occur.
+* We do releases every 3 months, at the end of each quarter, as described in the
+  [release schedule](RELEASES.md#release-schedule).
 * Take a look at open issues tagged with the current release, by
   [searching](https://github.com/envoyproxy/envoy/issues) for
   "is:open is:issue milestone:[current milestone]" and either hold off until
   they are fixed or bump them to the next milestone.
 * Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any
-  particularly risky PRs until after the release is tagged. This is because we currently don't use
-  release branches and assume that master is RC quality at all times.
+  particularly risky PRs until after the release is tagged. This is because we aim for master to be
+  at release candidate quality at all times.
 * Do a final check of the [release notes](docs/root/intro/version_history.rst) and make any needed
   corrections.
 * Switch the [VERSION](VERSION) from a "dev" variant to a final variant. E.g., "1.6.0-dev" to
@@ -90,6 +89,8 @@ or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/get
 * Create a [tagged release](https://github.com/envoyproxy/envoy/releases). The release should
   start with "v" and be followed by the version number. E.g., "v1.6.0". **This must match the
   [VERSION](VERSION).**
+* Create a branch from the tagged release, e.g. "release/v1.6". It will be used for the
+  [stable releases](RELEASES.md#stable-releases).
 * Monitor the CircleCI tag build to make sure that the final docker images get pushed along with
   the final docs. The final documentation will end up in the
   [envoyproxy.github.io repository](https://github.com/envoyproxy/envoyproxy.github.io/tree/master/docs/envoy).

RELEASES.md

@@ -0,0 +1,70 @@
+# Release Process
+
+## Active development
+
+Active development is happening on the `master` branch, and a new version is released from it
+at the end of each quarter.
+
+## Stable releases
+
+Stable releases of Envoy include:
+
+* Extended maintenance window (any version released in the last 12 months).
+* Security fixes backported from the `master` branch (including those deemed not worthy
+  of creating a CVE).
+* Stability fixes backported from the `master` branch (anything that can result in a crash,
+  including crashes triggered by a trusted control plane).
+* Bugfixes, deemed worthwhile by the maintainers of stable releases.
+
+### Hand-off
+
+Hand-off to the maintainers of stable releases happens after Envoy maintainers release a new
+version from the `master` branch by creating a `vX.Y.0` tag and a corresponding `release/vX.Y`
+branch, with merge permissions given to the release manager of stable releases, and CI configured
+to execute tests on it.
+
+### Security releases
+
+Critical security fixes are owned by the Envoy security team, which provides fixes for the
+`master` branch, and the latest release branch. Once those fixes are ready, the maintainers
+of stable releases backport them to the remaining supported stable releases.
+
+### Backports
+
+All other security and reliability fixes can be nominated for backporting to stable releases
+by Envoy maintainers, Envoy security team, the change author, or members of the Envoy community
+by adding the `backport/review` or `backport/approved` label (this can be done using [repokitteh]'s
+`/backport` command). Changes nominated by the change author and/or members of the Envoy community
+are evaluated for backporting on a case-by-case basis, and require approval from either the release
+manager of stable release, Envoy maintainers, or Envoy security team. Once approved, those fixes
+are backported from the `master` branch to all supported stable branches by the maintainers of
+stable releases. New stable versions from non-critical security fixes are released on a regular
+schedule, initially aiming for the bi-weekly releases.
+
+### Release management
+
+Release managers of stable releases are responsible for approving and merging backports, tagging
+stable releases and sending announcements about them. This role is rotating on a quarterly basis.
+
+| Quarter |       Release manager        |
+|:-------:|:----------------------------:|
+| 2020 Q1 | Piotr Sikora ([PiotrSikora]) |
+
+## Release schedule
+
+In order to accommodate downstream projects, new Envoy releases are produced on a fixed release
+schedule (at the end of each quarter), with an acceptable delay of up to 2 weeks, with a hard
+deadline of 3 weeks.
+
+| Version |  Expected  |   Actual   | Difference | End of Life |
+|:-------:|:----------:|:----------:|:----------:|:-----------:|
+| 1.12.0  | 2019/09/30 | 2019/10/31 |  +31 days  | 2020/10/31  |
+| 1.13.0  | 2019/12/31 | 2020/01/20 |  +20 days  | 2021/01/20  |
+| 1.14.0  | 2020/03/31 |            |            |             |
+| 1.15.0  | 2020/06/30 |            |            |             |
+| 1.16.0  | 2020/09/30 |            |            |             |
+| 1.17.0  | 2020/12/31 |            |            |             |
+
+
+[repokitteh]: https://github.com/repokitteh
+[PiotrSikora]: https://github.com/PiotrSikora

api/BUILD

@@ -30,6 +30,7 @@ proto_library(
         "//envoy/config/filter/http/adaptive_concurrency/v2alpha:pkg",
         "//envoy/config/filter/http/aws_request_signing/v2alpha:pkg",
         "//envoy/config/filter/http/buffer/v2:pkg",
+        "//envoy/config/filter/http/cache/v2alpha:pkg",
         "//envoy/config/filter/http/cors/v2:pkg",
         "//envoy/config/filter/http/csrf/v2:pkg",
         "//envoy/config/filter/http/dynamic_forward_proxy/v2alpha:pkg",
@@ -162,6 +163,7 @@ proto_library(
         "//envoy/extensions/filters/http/adaptive_concurrency/v3:pkg",
         "//envoy/extensions/filters/http/aws_request_signing/v3:pkg",
         "//envoy/extensions/filters/http/buffer/v3:pkg",
+        "//envoy/extensions/filters/http/cache/v3alpha:pkg",
         "//envoy/extensions/filters/http/cors/v3:pkg",
         "//envoy/extensions/filters/http/csrf/v3:pkg",
         "//envoy/extensions/filters/http/dynamic_forward_proxy/v3:pkg",

api/STYLE.md

@@ -120,6 +120,10 @@ Extensions must currently be added as v2 APIs following the [package
 organization](#package-organization) above.
 To add an extension config to the API, the steps below should be followed:
 
+1. If this is still WiP and subject to breaking changes, use `vNalpha` instead of `vN` in steps
+   below. Refer to the [Cache filter config](envoy/config/filter/http/cache/v2alpha/cache.proto)
+   as an example of `v2alpha`, and the
+   [Buffer filter config](envoy/config/filter/http/buffer/v2/buffer.proto) as an example of `v2`.
 1. Place the v2 extension configuration `.proto` in `api/envoy/config`, e.g.
    `api/envoy/config/filter/http/foobar/v2/foobar.proto` together with an initial BUILD file:
    ```
@@ -132,13 +136,15 @@ To add an extension config to the API, the steps below should be followed:
        )
    ```
 1. Add to the v2 extension config proto `import "udpa/annotations/migrate.proto";`
-2. Add to the v2 extension config proto a package level `option (udpa.annotations.file_migrate).move_to_package = "envoy.extensions.filters.http.foobar.v3";`.
-   This places the filter in the correct [v3 package hierarchy](#package-organization).
-3. Add a reference to the v2 extension config in (1) in [api/docs/BUILD](docs/BUILD).
-4. Run `./tools/proto_format fix`. This should regenerate the `BUILD` file,
+1. Add to the v2 extension config proto a file level `option (udpa.annotations.file_migrate).move_to_package = "envoy.extensions.filters.http.foobar.v3";`.
+   This places the filter in the correct [v3 package hierarchy](#package-organization). 
+1. If this is still WiP and subject to breaking changes, import
+   `udpa/annotations/status.proto` and set `option (udpa.annotations.file_status).work_in_progress = true;`.
+1. Add a reference to the v2 extension config in (1) in [api/docs/BUILD](docs/BUILD).
+1. Run `./tools/proto_format fix`. This should regenerate the `BUILD` file,
    reformat `foobar.proto` as needed and also generate the v3 extension config,
    together with shadow API protos.
-4. `git add api/ generated_api_shadow/` to add any new files to your Git index.
+1. `git add api/ generated_api_shadow/` to add any new files to your Git index.
 
 ## API annotations
 
@@ -177,3 +183,5 @@ metadata. We describe these annotations below by category.
 * `option (udpa.annotations.file_migrate).move_to_package = "<package name>";`
   to denote that in the next major version of the API, the file will be moved to
   the given package. This is consumed by `protoxform`.
+* `option (udpa.annotations.file_status).work_in_progress = true;` to denote a
+  file that is still work-in-progress and subject to breaking changes.

api/bazel/repository_locations.bzl

@@ -13,8 +13,8 @@ GOOGLEAPIS_SHA = "a45019af4d3290f02eaeb1ce10990166978c807cb33a9692141a076ba46d14
 PROMETHEUS_GIT_SHA = "99fa1f4be8e564e8a6b613da7fa6f46c9edafc6c"  # Nov 17, 2017
 PROMETHEUS_SHA = "783bdaf8ee0464b35ec0c8704871e1e72afa0005c3f3587f65d9d6694bf3911b"
 
-UDPA_GIT_SHA = "edbea6a78f6d1ba34edc69c53a396b1d88d59651"  # Dec 30, 2019
-UDPA_SHA256 = "8cabd617b68354fa8b4adab8a031f80c10e2ea43f57d5f6210bc7b3ebb79b684"
+UDPA_GIT_SHA = "db4b343e48c1264bb4d9ff491b059300701dc7c7"  # Jan 24, 2020
+UDPA_SHA256 = "800624f44592a24898f133e39ae7fbb7a6c4b85bdddd448185fb7e277f097a56"
 
 ZIPKINAPI_RELEASE = "0.2.2"  # Aug 23, 2019
 ZIPKINAPI_SHA256 = "688c4fe170821dd589f36ec45aaadc03a618a40283bc1f97da8fa11686fc816b"

api/docs/BUILD

@@ -36,6 +36,7 @@ proto_library(
         "//envoy/config/filter/http/adaptive_concurrency/v2alpha:pkg",
         "//envoy/config/filter/http/aws_request_signing/v2alpha:pkg",
         "//envoy/config/filter/http/buffer/v2:pkg",
+        "//envoy/config/filter/http/cache/v2alpha:pkg",
         "//envoy/config/filter/http/cors/v2:pkg",
         "//envoy/config/filter/http/csrf/v2:pkg",
         "//envoy/config/filter/http/dynamic_forward_proxy/v2alpha:pkg",

api/envoy/api/v2/auth/cert.proto

@@ -289,6 +289,16 @@ message CertificateValidationContext {
   // An optional list of Subject Alternative name matchers. Envoy will verify that the
   // Subject Alternative Name of the presented certificate matches one of the specified matches.
   //
+  // When a certificate has wildcard DNS SAN entries, to match a specific client, it should be
+  // configured with exact match type in the :ref:`string matcher <envoy_api_msg_type.matcher.StringMatcher>`.
+  // For example if the certificate has "\*.example.com" as DNS SAN entry, to allow only "api.example.com",
+  // it should be configured as shown below.
+  //
+  // .. code-block:: yaml
+  //
+  //  match_subject_alt_names:
+  //    exact: "api.example.com"
+  //
   // .. attention::
   //
   //   Subject Alternative Names are easily spoofable and verifying only them is insecure,
@@ -435,6 +445,11 @@ message DownstreamTlsContext {
   }];
 }
 
+message GenericSecret {
+  // Secret of generic type and is available to filters.
+  core.DataSource secret = 1 [(udpa.annotations.sensitive) = true];
+}
+
 message SdsSecretConfig {
   // Name (FQDN, UUID, SPKI, SHA256, etc.) by which the secret can be uniquely referred to.
   // When both name and config are specified, then secret can be fetched and/or reloaded via
@@ -444,6 +459,7 @@ message SdsSecretConfig {
   core.ConfigSource sds_config = 2;
 }
 
+// [#next-free-field: 6]
 message Secret {
   // Name (FQDN, UUID, SPKI, SHA256, etc.) by which the secret can be uniquely referred to.
   string name = 1;
@@ -454,5 +470,7 @@ message Secret {
     TlsSessionTicketKeys session_ticket_keys = 3;
 
     CertificateValidationContext validation_context = 4;
+
+    GenericSecret generic_secret = 5;
   }
 }

api/envoy/api/v2/core/protocol.proto

@@ -24,6 +24,12 @@ message UpstreamHttpProtocolOptions {
   // upstream connections based on the downstream HTTP host/authority header, as seen by the
   // :ref:`router filter <config_http_filters_router>`.
   bool auto_sni = 1;
+
+  // Automatic validate upstream presented certificate for new upstream connections based on the
+  // downstream HTTP host/authority header, as seen by the
+  // :ref:`router filter <config_http_filters_router>`.
+  // This field is intended to set with `auto_sni` field.
+  bool auto_san_validation = 2;
 }
 
 message HttpProtocolOptions {

api/envoy/api/v2/route/route_components.proto

@@ -1124,6 +1124,9 @@ message Decorator {
   //   by the :ref:`x-envoy-decorator-operation
   //   <config_http_filters_router_x-envoy-decorator-operation>` header.
   string operation = 1 [(validate.rules).string = {min_bytes: 1}];
+
+  // Whether the decorated details should be propagated to the other party. The default is true.
+  google.protobuf.BoolValue propagate = 2;
 }
 
 message Tracing {

api/envoy/config/accesslog/v2/als.proto

@@ -17,7 +17,7 @@ option (udpa.annotations.file_migrate).move_to_package = "envoy.extensions.acces
 
 // [#protodoc-title: gRPC Access Log Service (ALS)]
 
-// Configuration for the built-in *envoy.http_grpc_access_log*
+// Configuration for the built-in *envoy.access_loggers.http_grpc*
 // :ref:`AccessLog <envoy_api_msg_config.filter.accesslog.v2.AccessLog>`. This configuration will
 // populate :ref:`StreamAccessLogsMessage.http_logs
 // <envoy_api_field_service.accesslog.v2.StreamAccessLogsMessage.http_logs>`.
@@ -38,7 +38,7 @@ message HttpGrpcAccessLogConfig {
   repeated string additional_response_trailers_to_log = 4;
 }
 
-// Configuration for the built-in *envoy.tcp_grpc_access_log* type. This configuration will
+// Configuration for the built-in *envoy.access_loggers.tcp_grpc* type. This configuration will
 // populate *StreamAccessLogsMessage.tcp_logs*.
 // [#extension: envoy.access_loggers.tcp_grpc]
 message TcpGrpcAccessLogConfig {

api/envoy/config/accesslog/v2/file.proto

@@ -16,7 +16,7 @@ option (udpa.annotations.file_migrate).move_to_package = "envoy.extensions.acces
 // [#extension: envoy.access_loggers.file]
 
 // Custom configuration for an :ref:`AccessLog <envoy_api_msg_config.filter.accesslog.v2.AccessLog>`
-// that writes log entries directly to a file. Configures the built-in *envoy.file_access_log*
+// that writes log entries directly to a file. Configures the built-in *envoy.access_loggers.file*
 // AccessLog.
 message FileAccessLog {
   // A path to a local file to which to write the access log entries.

api/envoy/config/accesslog/v3/accesslog.proto

@@ -30,9 +30,9 @@ message AccessLog {
   // The name of the access log implementation to instantiate. The name must
   // match a statically registered access log. Current built-in loggers include:
   //
-  // #. "envoy.file_access_log"
-  // #. "envoy.http_grpc_access_log"
-  // #. "envoy.tcp_grpc_access_log"
+  // #. "envoy.access_loggers.file"
+  // #. "envoy.access_loggers.http_grpc"
+  // #. "envoy.access_loggers.tcp_grpc"
   string name = 1;
 
   // Filter which is used to determine if the access log needs to be written.
@@ -41,11 +41,11 @@ message AccessLog {
   // Custom configuration that depends on the access log being instantiated. Built-in
   // configurations include:
   //
-  // #. "envoy.file_access_log": :ref:`FileAccessLog
+  // #. "envoy.access_loggers.file": :ref:`FileAccessLog
   //    <envoy_api_msg_extensions.access_loggers.file.v3.FileAccessLog>`
-  // #. "envoy.http_grpc_access_log": :ref:`HttpGrpcAccessLogConfig
+  // #. "envoy.access_loggers.http_grpc": :ref:`HttpGrpcAccessLogConfig
   //    <envoy_api_msg_extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfig>`
-  // #. "envoy.tcp_grpc_access_log": :ref:`TcpGrpcAccessLogConfig
+  // #. "envoy.access_loggers.tcp_grpc": :ref:`TcpGrpcAccessLogConfig
   //    <envoy_api_msg_extensions.access_loggers.grpc.v3.TcpGrpcAccessLogConfig>`
   oneof config_type {
     google.protobuf.Any typed_config = 4;

api/envoy/config/core/v3/protocol.proto

@@ -29,6 +29,12 @@ message UpstreamHttpProtocolOptions {
   // upstream connections based on the downstream HTTP host/authority header, as seen by the
   // :ref:`router filter <config_http_filters_router>`.
   bool auto_sni = 1;
+
+  // Automatic validate upstream presented certificate for new upstream connections based on the
+  // downstream HTTP host/authority header, as seen by the
+  // :ref:`router filter <config_http_filters_router>`.
+  // This field is intended to set with `auto_sni` field.
+  bool auto_san_validation = 2;
 }
 
 message HttpProtocolOptions {

api/envoy/config/filter/accesslog/v2/accesslog.proto

@@ -23,9 +23,9 @@ message AccessLog {
   // The name of the access log implementation to instantiate. The name must
   // match a statically registered access log. Current built-in loggers include:
   //
-  // #. "envoy.file_access_log"
-  // #. "envoy.http_grpc_access_log"
-  // #. "envoy.tcp_grpc_access_log"
+  // #. "envoy.access_loggers.file"
+  // #. "envoy.access_loggers.http_grpc"
+  // #. "envoy.access_loggers.tcp_grpc"
   string name = 1;
 
   // Filter which is used to determine if the access log needs to be written.
@@ -34,11 +34,11 @@ message AccessLog {
   // Custom configuration that depends on the access log being instantiated. Built-in
   // configurations include:
   //
-  // #. "envoy.file_access_log": :ref:`FileAccessLog
+  // #. "envoy.access_loggers.file": :ref:`FileAccessLog
   //    <envoy_api_msg_config.accesslog.v2.FileAccessLog>`
-  // #. "envoy.http_grpc_access_log": :ref:`HttpGrpcAccessLogConfig
+  // #. "envoy.access_loggers.http_grpc": :ref:`HttpGrpcAccessLogConfig
   //    <envoy_api_msg_config.accesslog.v2.HttpGrpcAccessLogConfig>`
-  // #. "envoy.tcp_grpc_access_log": :ref:`TcpGrpcAccessLogConfig
+  // #. "envoy.access_loggers.tcp_grpc": :ref:`TcpGrpcAccessLogConfig
   //    <envoy_api_msg_config.accesslog.v2.TcpGrpcAccessLogConfig>`
   oneof config_type {
     google.protobuf.Struct config = 3 [deprecated = true];

api/envoy/config/filter/http/cache/v2alpha/BUILD

@@ -0,0 +1,13 @@
+# DO NOT EDIT. This file is generated by tools/proto_sync.py.
+
+load("@envoy_api//bazel:api_build_system.bzl", "api_proto_package")
+
+licenses(["notice"])  # Apache 2
+
+api_proto_package(
+    deps = [
+        "//envoy/api/v2/route:pkg",
+        "//envoy/type/matcher:pkg",
+        "@com_github_cncf_udpa//udpa/annotations:pkg",
+    ],
+)