Add ProtoApiScrubber HTTP filter configuration proto #38155
Conversation
Signed-off-by: Sumit Kumar <[email protected]>
|
Hi @sumitkmr2, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Sumit Kumar <[email protected]>
Signed-off-by: Sumit Kumar <[email protected]>
Signed-off-by: Sumit Kumar <[email protected]>
|
/docs |
|
Docs for this Pull Request will be rendered here: https://storage.googleapis.com/envoy-pr/38155/docs/index.html The docs are (re-)rendered each time the CI |
Signed-off-by: Sumit Kumar <[email protected]>
Signed-off-by: Sumit Kumar <[email protected]>
Signed-off-by: Sumit Kumar <[email protected]>
|
Overall, Looks good to me. Do you also plan to update the fields in commit message? I think it's safe to mention that the Design Document has been approved internally by the team at Google. |
Thanks Divya! I have updated the commit message. |
| option (udpa.annotations.file_status).package_version_status = ACTIVE; | ||
| option (xds.annotations.v3.file_status).work_in_progress = true; | ||
|
|
||
| // [#not-implemented-hide:] |
There was a problem hiding this comment.
@sumitkmr2 i would like to review the docs here - i can see issues in the source - but kinda need it rendered
i think because of this its not currently rendering - could you temporarily disable it please
Signed-off-by: Sumit Kumar <[email protected]>
Signed-off-by: Sumit Kumar <[email protected]>
api/envoy/extensions/filters/http/proto_api_scrubber/v3/config.proto
Outdated
Show resolved
Hide resolved
|
docs build is failing with Did you forget to add 'envoy.filters.http.proto_api_scrubber' to extensions_build_config.bzl, extensions_metadata.yaml, contrib_build_config.bzl, or contrib/extensions_metadata.yaml?i think it needs to be setup correctly - wondering if there is an implementation - its not so common to add just an api without implementation |
Signed-off-by: Sumit Kumar <[email protected]>
@phlax: Currently, we don't have the filter implementation ready however, it is planned to be completed in the coming ~2 months. This PR is to unblock other dependencies within Google which rely on the filter config proto. Please let me know if there are any concerns on that. |
|
@sumitkmr2 i had a few concerns. One is that the design doc has not been shared with Envoy maintainers - who are ultimately responsible for approving and then maintaining this. The other concern is wrt docs - historically api docs that are added In this case I can see several ~nit issues - i can feedback some of those now - but its hard without seeing the page actually rendered. There is also some higher level feedback - eg explanations of how the filter works (and examples) generally dont want to be in the API docs - we have a config reference section in the docs for that, so better to add docs there and link from here - another is to use yaml for end-user examples - this type of review is especially hard without rendering I am reviewing our process with adding I am happy to land this but i think we need to ensure these points are followed up on - so probably we should add a ticket to track |
|
cc @adisuissa |
| // } | ||
| // } | ||
| // | ||
| // Note that the fields `debug_info` and `book.debug_info` are filtered out from |
There was a problem hiding this comment.
| // Note that the fields `debug_info` and `book.debug_info` are filtered out from | |
| // Note that the fields ``debug_info`` and ``book.debug_info`` are filtered out from |
| // } | ||
| // | ||
| // Note that the fields `debug_info` and `book.debug_info` are filtered out from | ||
| // the response since the request entitlement of type "USER_TYPE" is PROD while |
There was a problem hiding this comment.
| // the response since the request entitlement of type "USER_TYPE" is PROD while | |
| // the response since the request entitlement of type ``USER_TYPE`` is ``PROD`` while |
| // | ||
| // Note that the fields `debug_info` and `book.debug_info` are filtered out from | ||
| // the response since the request entitlement of type "USER_TYPE" is PROD while | ||
| // the restrictions on the fields `debug_info` and `book.debug_info` is DEV. |
There was a problem hiding this comment.
| // the restrictions on the fields `debug_info` and `book.debug_info` is DEV. | |
| // the restrictions on the fields ``debug_info`` and ``book.debug_info`` is ``DEV``. |
| // embedded in the ``Datasource.inline_bytes``. | ||
| config.core.v3.DataSource data_source = 1; | ||
|
|
||
| // Unimplemented, the key of proto descriptor TypedMetadata. |
There was a problem hiding this comment.
| // Unimplemented, the key of proto descriptor TypedMetadata. | |
| // Unimplemented, the key of proto descriptor ``TypedMetadata``. |
| // Data sources for the request entitlements. | ||
| // Entitlements are matched with restrictions of the same name at runtime. | ||
| // Make sure that the entitlement source is present for each of the | ||
| // corresponding restrictions. |
There was a problem hiding this comment.
| // corresponding restrictions. | |
| // corresponding restrictions: |
| // Key - entitlement name | ||
| // Value - entitlement source |
There was a problem hiding this comment.
| // Key - entitlement name | |
| // Value - entitlement source | |
| // - Key - entitlement name | |
| // - Value - entitlement source |
not sure if any/all of Key/Value/name/source are "literals" - if so they should be double backticked - im guessing its just name and source that are literals
| // Key - Fully qualified method name. | ||
| // - ``${package}.${Service}.${Method}``, like | ||
| // - ``endpoints.examples.bookstore.BookStore.GetShelf`` | ||
| // Value - Method restrictions. |
There was a problem hiding this comment.
its not clear how this will render - but almost certainly not how you want/expect
| // Restrictions that apply to request fields of the method. | ||
| // Key - field mask like path of the field eg, foo.bar.baz | ||
| // Value - Restrictions map containing the mapping from restriction type to | ||
| // the restriction values. |
There was a problem hiding this comment.
| // Restrictions that apply to request fields of the method. | |
| // Key - field mask like path of the field eg, foo.bar.baz | |
| // Value - Restrictions map containing the mapping from restriction type to | |
| // the restriction values. | |
| // Restrictions that apply to request fields of the method: | |
| // - Key - field mask like path of the field eg, ``foo.bar.baz`` | |
| // - Value - Restrictions map containing the mapping from restriction type to | |
| // the restriction values. |
with these - not sure if we want a list but currently this would all just render on one line
| map<string, RestrictionMap> request_field_restrictions = 1; | ||
|
|
||
| // Restrictions that apply to response fields of the method. | ||
| // Key - field mask like path of the field eg, foo.bar.baz |
|
@sumitkmr2 If the filter is only useful for a Google use case, does it make sense to implement it as a Google filter extension in the Google source repository instead of in open-source? |
|
looks like this is waiting on PR author |
Commit Message: Add ProtoApiScrubber HTTP filter configuration proto.
Additional Description: We are adding a new envoy filter for API filtering for the APIs which are backed by protobuf definitions. This is the first PR for the same which contains just the filter config. Subsequent PRs will include adding more fields to the filter config to support further usecases, filter runtime code, etc. The design doc for this filter is internally approved within Google.
Risk Level: NONE
Testing: NOT DONE. Will be done once the actual filter runtime code is added.
Docs Changes: NOT DONE.
Release Notes: NA. Will be added once the actual filter runtime code is added.
Platform Specific Features: NONE.
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]