This PR replaces deprecated HTTP links by HTTPS links for security and consistency.
Signed-off-by: Vu Cong Tuan <tuanvc@vn.fujitsu.com>
Mirrored from https://github.com/envoyproxy/envoy @ b47112f62b5186bb087bdf335f6df6fb072e2a46
* api: add proto options for java
* add ci for checking proto options
Signed-off-by: Penn (Dapeng) Zhang <zdapeng@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 02659d411332e9f20d229f482931c15304ea17fd
I think this broke in a recent refactor.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 866597fcb8cc3cdd53a767d66755506036261f3c
adds the required visibility rules and delegates the rest to the generic
api_proto_library. I tested the change by doing the following without
getting errors.
./ci/run_envoy_docker.sh './ci/do_ci.sh docs'
I changed the BUILD files using the following commands.
/envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/api_proto_library(/api_proto_library_internal(/g'
envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/"api_proto_library"/"api_proto_library_internal"/g'
Signed-off-by: mickey <mickeyju@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4b871c0ab9350882271a490adcee44e613ed9807
This PR extends the current Ext_Authz filter to allow optional HTTP attributes being passed from the Authorization service down to client or, to the upstream services. I would like to get some feedback on the changes to the current gRPC async client and filter before moving to implementation of HTTP part of this extension and tests.
*issue: #2828
Risk Level: Medium
Testing: Manual, unit testing.
Docs Changes: envoyproxy/data-plane-api#563
Signed-off-by: Gabriel <gsagula@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5244597e93c70b4945c03a9fc55f8924a2da6fbc
*Risk Level*: None
*Testing*: bazel test //test/...
*Docs Changes*: n/a
*Release Notes*: n/a
Found with buildifier.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e8964c83f359916ecbf9c01a03ade3c92aac479
Signed-off-by: Daniel Hochman <danielhochman@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 81d37e775bd064a8f01c64a79175eab4d21bee7e
Added protos to support Role Based Access Control in Envoy.
Also removed existing auth.proto because the new RBAC proto is a replacement of it.
Ealier discussions at
envoyproxy/data-plane-api#586.
Signed-off-by: Limin Wang <liminwang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 13de384ab34428af99c53201f6b3c95991b7ae10
1) Add ability to runtime filter to configure default, divisor, and
whether independent randomness is used.
2) Also add LE to the comparison filter.
Signed-off-by: Matt Klein <mklein@lyft.com>
v2 api changes: Use oneof to specify header match options, based on value(exact_match), regex or range.
The existing value and regex fields will be deprecated. Use the header_match_specfier oneof instead.
Add a new range.proto (envoy.type.v2) for the range type definition.
The SInt64Range message is defined in envoy.type.v2 range.proto.
It consists of start and end (inclusive, exclusive) sint64 values.
v1 api: Add a range_match object to the route headers json. Presence of this object indicates range based route match.
Example: For the below route config:
{
"prefix": "/",
"cluster": "PartitionB",
"name": "PartitionKey",
"range_match": { "start": 0, "end": 10}
}
In the incoming request, if the PartitionKey header value = 0, route match succeeds. Route match fails if the header value = 10, -10, "somestring".
This feature can be used for request routing with Service Fabric stateful services, to route to the desired partition with the [ranged partitioning scheme](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-partitioning#ranged-partitioning-scheme)
Signed-off-by: Kavya Kotacherry <kavyako@microsoft.com>
data-plane-api(CircleCI)
Kuat
Matt Klein
Kavya Kotacherry - MSFT