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
support ext_authz v3 API, still serve v2 #217
Conversation
4f37f6d
to
7a93157
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compatibility is definitely nice to have, so +1 there. I have two questions that I think we need to answer (which we've talked about offline):
-
What config changes are required on the Envoy (and also Istio) side? E.g., does the filter configuration change significantly? An example would be useful.
-
What policy changes are required when switching from v2 to v3? Does using protojson change anything? Examples would be useful.
I've had a close look at the proto defs for v2 and v3, and played around some more, capturing my findings in https://github.com/open-policy-agent/opa-envoy-plugin/pull/217/files#diff-9119e7abecbea4bb21414d5dbc6de682261b4fc2840aec10485494feb01125dd Summing up, I think it's preferable to go with protojson in v3; an alternative we could explore is adding a configurable to let people opt-in to the old behaviour, using encoding/json instead. |
dbb18ea
to
b30fab5
Compare
Remaining TODOs:
(💭 It's interesting how our current set of unit tests seems to live exactly in the overlap of v2/v3 and encoding/json / protojson. While I'd like to expand them some day, I think it's better to focus on one set of those, and I'd think that's v3+protojson.) |
879ab03
to
b288771
Compare
✔️ ensured that |
54bb17e
to
e41df82
Compare
ℹ️ Rebasing now, I'll squash post-review. |
6c00fe7
to
67477dc
Compare
Please note that I haven't updated the top-level |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. A couple questions but nothing blocking.
internal/internal.go
Outdated
respV2 := v2Response(respV3) | ||
if code := stop(); code != nil { | ||
respV2.Status = code | ||
} | ||
return respV2, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the conversion is relatively quick and accounts for a small portion (e.g., 1%) of the check response time...is that right? Since we're not including it in the decision log metrics, I just want to make sure it's negligible and can be ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was my intention to include it in the decision log time, that's where the awkward stop
handling came from. It's converted in L769 right before stopping the time in L770. I might be misled about how it works...? 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops. I didn't look closely enough at what stop()
was doing. The metric tracking looks fine then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, we'll want to call stop()
regardless of whether an error occurred--we want a decision log emitted in the case of errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that's an oversight. We'll want stop
to happen for the L756 case, too, indeed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've fixed it, and duplicated a few of the unit tests for v2, to cover this logic.
⏸️ I'll address all comments and proceed with merging this tomorrow. 😃 |
I'll squash and merge. Let's take it from here in follow-up PRs. |
77be495
to
2875814
Compare
This change makes opa-envoy-plugin expose two gRPC services: envoy.service.auth.v2.Authorization and envoy.service.auth.v3.Authorization. Since switching to v3 requires user action already, we've taken this chance to migrate the representation of the v3 CheckRequest to the specified JSON mapping. See the README.md for details. That aside, if you're using the v2 API, no changes to your policies are required, and you can keep using the v2 API for some time. It's TBD when we are going to drop support for it. This change also brings another input value that lets you determine the request version (v2/v3) and its encoding (protojson for the official mapping, "encoding/json" for the one used with v2). With respect to the software we're integrating with here, note - Envoy 1.13 is the first version to support the v3 API. - Istio 1.7.0 is the first version that lets you configure the v3 filters required to use the v3 API with Envoy. Support for the 1.6 series of Istio has been ended in Nov 21 2020. - That first version of Envoy released in 2021, presumably 1.18, will drop support for the v2 API. The `examples/istio/quick_start.yaml` file has been adapted: 1. it's using the v3 API 2. its hardcoded TLS certs (generated with `build/gen-tls-certs.sh`) work with a service that's built with Go 1.15 (which refuses CN in favour of SNI records) Signed-off-by: Stephan Renatus <stephan@styra.com>
Signed-off-by: Stephan Renatus <stephan@styra.com>
2875814
to
fa2a2d2
Compare
Also updates kind to 0.9.0, required for Istio 1.7.0. (Oversight of open-policy-agent#217) Signed-off-by: Stephan Renatus <stephan@styra.com>
Also updates kind to 0.9.0, required for Istio 1.7.0. (Oversight of open-policy-agent#217) Signed-off-by: Stephan Renatus <stephan@styra.com>
Also updates kind to 0.9.0, required for Istio 1.7.0. (Oversight of #217) Signed-off-by: Stephan Renatus <stephan@styra.com>
This will make opa-envoy-plugin expose both the v2 and the v3 APIs:
As such, we should be able to use it with in either variant. New features will only be added to the v3 API, and v2 is to be considered deprecated, and will be removed in the future, timeline TBD.
There's still some work to do here:
figure out the impact of switching to
protojson
for converting the CheckRequest into OPA's input, and determine if we want to use v3 as a chance to do that.documentation:
testing: the unit tests use v3, the e2e tests use v2 still
Fixes open-policy-agent/opa#2798.