Running make gen for some other change resulted in many additional
changes showing up in my local repo. So pushing a separate review for the same.
Signed-off-by: Faseela K <faseela.k@est.tech>
* support x-jwt-claim in virtual service
* update
* update to request authN
* revert vs
* Apply suggestions from code review
Co-authored-by: Sven Mawson <sven@google.com>
* update
Co-authored-by: Sven Mawson <sven@google.com>
* Clarify request authentication root namespace scope.
* typo fix.
* make gen.
* make gen.
* clarified all workloads instead.
* update with authz example.
* Update security/v1beta1/request_authentication.proto
Co-authored-by: Sven Mawson <sven@google.com>
* Update security/v1beta1/request_authentication.proto
Co-authored-by: Sven Mawson <sven@google.com>
* update the doc gen.
Co-authored-by: Lin Sun <lin.sun@solo.io>
Co-authored-by: Sven Mawson <sven@google.com>
* Clarify portLevelMtls requirement
* Run make gen
* Update security/v1beta1/peer_authentication.proto
Co-authored-by: Sven Mawson <sven@google.com>
* Rerun make gen
Co-authored-by: Sven Mawson <sven@google.com>
https://docs.buf.build/
Buf is the successor to https://github.com/uber/prototool which we
already use for linting.
This dramatically simplifies our Makefiles, which are both extremely
complicated and have led to numerous bugs historically, such as
https://github.com/istio/api/issues/1678.
This will make changes to the generation much simpler as well. For
example, to migrate to gogo protobuf, we will just need to change `gogo`
-> `go` in one location, rather than trying to wrangle 500 lines of
Makefiles. Additionally, its quite a bit faster - the whole proto stuff
is done in <1s now.
* update external action API
* more generic in MeshConfig
* address comments
* more comments
* use ExternalProvider and many more updates
* use provider
* require fully qualified name in service
* add fail_open and share common settings for HTTP and GRPC
* update for extension_providers and EXTENDED action
* address comments
* make port required
* change to CUSTOM action
* fix
* create remote_ip_blocks in Source
By adding remote_ip_blocks and not_remote_ip_blocks in Source,
an AuthorizationPolicy can trigger actions based on the original
client IP address gleaned from the X-Forwarded-For header or the
proxy protocol.
* update comment to show that ip_blocks match on IP packet source address
* make reference to numTrustedProxies in remote_ip docs
* fix URL for gateway network topology
* add external action to authorization policy
* remove config for now and update comments
* use custom config that is mostly based on Envoy ext_authz with minimal changes
* fix comments
Every other API is named `<kind in snake case>.proto`, but authz. It is
named authorization.policy. This impacts the generated code. For
consistency, renaming it to match all of our other APIs
John Howard