Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: mark matching API and related features as alpha #16210

Merged
merged 13 commits into from
May 21, 2021
4 changes: 4 additions & 0 deletions api/STYLE.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,10 @@ In addition, the following conventions should be followed:
implementation. These indicate that the entity is not implemented in Envoy and the entity
should be hidden from the Envoy documentation.

* Use a `[#alpha:]` annotation in comments for messages that are considered alpha
and are not subject to the threat model. This differs from the work-in-progress/alpha tagging
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to update this comment given it's now alpha tagging :-)

I think also worth calling out that things tagged alpha are not yet subject to the stable API policies and security release policies.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm we still have extension level alpha tagging which differs from this alpha tag which is the only way to mark messages within core as alpha. What kind of change were you thinking about?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to resolve the two, and have alpha tagging for extensions be functionally the same as alpha tagging for messages and fields, which is basically that both are WIP, not stable APIs and less trusted code.

of extensions described below in that it can be applied to configuration within the core API.

* Always use plural field names for `repeated` fields, such as `filters`.

* Due to the fact that we consider JSON/YAML to be first class inputs, we cannot easily change a
Expand Down
2 changes: 1 addition & 1 deletion api/envoy/config/common/matcher/v3/matcher.proto
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
// As an on_no_match might result in another matching tree being evaluated, this process
// might repeat several times until the final OnMatch (or no match) is decided.
//
// This API is a work in progress.
// [#alpha:]
message Matcher {
// What to do if a match is successful.
message OnMatch {
Expand Down
2 changes: 1 addition & 1 deletion api/envoy/config/common/matcher/v4alpha/matcher.proto

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,8 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
// Wrapper around an existing extension that provides an associated matcher. This allows
// decorating an existing extension with a matcher, which can be used to match against
// relevant protocol data.
//
// [#alpha:]
message ExtensionWithMatcher {
// The associated matcher.
config.common.matcher.v3.Matcher matcher = 1 [(validate.rules).message = {required: true}];
Expand Down

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE;
// :ref:`ExecuteFilterAction <envoy_api_msg_extensions.filters.http.composite.v3.ExecuteFilterAction>`)
// which filter configuration to create and delegate to.
//
// [#alpha:]
message Composite {
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,11 @@
Composite Filter
================

.. attention::

The composite filter is in alpha and is currently under active development.
Capabilities will be expanded over time and the configuration structures are likely to change.

The composite filter allows delegating filter actions to a filter specified by a
:ref:`match result <arch_overview_matching_api>`. The purpose of this is to allow different filters
or filter configurations to be selected based on the incoming request, allowing for more dynamic
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,11 @@
Matching API
============

.. attention::

The matching API is experimental and is currently under active development.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: s/experimental/alpha/

Capabilities will be expanded over time and the configuration structures are likely to change.

Envoy makes use of a :ref:`matching API <envoy_v3_api_msg_config.common.matcher.v3.Matcher>`
to allow the various subsystems to express actions that should be performed based on incoming data.

Expand Down
8 changes: 5 additions & 3 deletions docs/root/intro/arch_overview/security/threat_model.rst
Original file line number Diff line number Diff line change
Expand Up @@ -77,9 +77,11 @@ case, an extension will explicitly state this in its documentation.
Core and extensions
-------------------

Anything in the Envoy core may be used in both untrusted and trusted deployments. As a consequence,
it should be hardened with this model in mind. Security issues related to core code will usually
trigger the security release process as described in this document.
Anything in the Envoy core may be used in both untrusted and trusted deployments, with the exception
of features explicitly marked as alpha; alpha features are only supported in trusted deployments
and do not qualify for treatment under the threat model below. As a consequence, the stable core should be hardened
with this model in mind. Security issues related to core code will usually trigger the security release process as
described in this document.

The following extensions are intended to be hardened against untrusted downstream and upstreams:

Expand Down

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion source/extensions/filters/http/composite/BUILD
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ envoy_cc_extension(
srcs = ["config.cc"],
hdrs = ["config.h"],
category = "envoy.filters.http",
security_posture = "robust_to_untrusted_downstream",
security_posture = "unknown",
deps = [
"//include/envoy/registry",
"//include/envoy/server:filter_config_interface",
Expand Down
4 changes: 4 additions & 0 deletions tools/api_proto_plugin/annotations.py
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@
# envoy.filters.network.http_connection_manager.
EXTENSION_ANNOTATION = 'extension'

# Used to mark something as alpha, excluding it from the threat model.
ALPHA_ANNOTATION = 'alpha'

# Not implemented yet annotation on leading comments, leading to hiding of
# field.
NOT_IMPLEMENTED_HIDE_ANNOTATION = 'not-implemented-hide'
Expand All @@ -33,6 +36,7 @@
VALID_ANNOTATIONS = set([
DOC_TITLE_ANNOTATION,
EXTENSION_ANNOTATION,
ALPHA_ANNOTATION,
EXTENSION_CATEGORY_ANNOTATION,
NOT_IMPLEMENTED_HIDE_ANNOTATION,
NEXT_FREE_FIELD_ANNOTATION,
Expand Down
8 changes: 7 additions & 1 deletion tools/protodoc/protodoc.py
Original file line number Diff line number Diff line change
Expand Up @@ -160,6 +160,12 @@ def format_comment_with_annotations(comment, type_name=''):
Returns:
A string with additional RST from annotations.
"""
alpha_warning = ''
if annotations.ALPHA_ANNOTATION in comment.annotations:
experimental_warning = (
'.. warning::\n This API is alpha and is not covered by the :ref:`threat model <arch_overview_threat_model>`.\n\n'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, we have a broader issue which we can resolve after we land this PR. We have both implementation and API alpha/experimental/unknown robustness status. An API is not really insecure in and of itself, this is an implementation attribute.

We really need a way to mark in the protos client specific implementation status details, since Envoy vs. gRPC support for a feature might have different implementation status.

I started to explore this in #11085, but it's not really something I have b/w for. Maybe @phlax this can be part of the docs/tooling roadmap?

CC @markdroth

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, it would be nice to have some generic solution for this kind of thing. Matt has been saying for a while that we need a way to have client-specific docs in the proto files, not just for API status but for any type of documentation. Although as the number of xDS clients grows, I'm not sure how feasible it will be to document all of the in the same proto files. But this is definitely something we need to come up with a good strategy for.

)

formatted_extension = ''
if annotations.EXTENSION_ANNOTATION in comment.annotations:
extension = comment.annotations[annotations.EXTENSION_ANNOTATION]
Expand All @@ -169,7 +175,7 @@ def format_comment_with_annotations(comment, type_name=''):
for category in comment.annotations[annotations.EXTENSION_CATEGORY_ANNOTATION].split(","):
formatted_extension_category += format_extension_category(category)
comment = annotations.without_annotations(strip_leading_space(comment.raw) + '\n')
return comment + formatted_extension + formatted_extension_category
return alpha_warning + comment + formatted_extension + formatted_extension_category


def map_lines(f, s):
Expand Down