-
Notifications
You must be signed in to change notification settings - Fork 89
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
Add support for system-internal-tls
in net-istio
#1085
Add support for system-internal-tls
in net-istio
#1085
Conversation
/assign @nak3, @skonto, @evankanderson for review /cc @dprotaso, @KauzClay for inputs/opinions on the discussion points (and - of course - also review if you'd like) |
/hold I'm going to look into the test failures. |
I like the suggestion to do https://github.com/knative/serving/issue/13472, particularly since we've seen it show up three times and within-cluster TLS is not an unreasonable desire. (Non-blocking, will review the rest soon.) |
One other thought: with websockets being defined for http2, I wonder whether we should simply run http2 to the queue-proxy and do the down-conversion there. Downside: we may get scale-from-zero wakeups for requests the app won't actually be able to handle. Upside: people can stop needing to worry about naming their port. |
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.
Initial review; this was less painful than I anticipated.
I synced with @KauzClay. Well come up with some GH-issues to track tasks out of the Findings document shortly to start working on that. But we'd need to agree on the contract and
I think it would be worth to look into this. Should we track/discuss this in a new issue?
That's a hopefully a good thing? ;) |
/test integration-tests /test latest-mesh |
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 guess we should add the same #114 for DestinationRules in cmd/controller/main.go
?
I don't know the reason. As far as I researched the commit history (you might already know but...)
The revert is waiting for knative/serving#8896 but knative/serving#8896 should be fixed most probably so we should bump the API to |
/test latest-mesh |
/unhold |
Overall looks good to me. With said, Istio has a large variety of network configuration so I am worried that adding a non-edge network feature conflicts with their features 😥 For example, does this |
@evankanderson Would you like to have another review? |
My personal take would be, if you use service-mesh, you do not need the Knative internal-encryption feature. I also would not invest in making this compatible with istios internal mesh certificates. |
442d207
to
35ebcb8
Compare
Codecov Report
@@ Coverage Diff @@
## main #1085 +/- ##
==========================================
+ Coverage 81.42% 81.66% +0.24%
==========================================
Files 18 19 +1
Lines 1599 1680 +81
==========================================
+ Hits 1302 1372 +70
- Misses 213 220 +7
- Partials 84 88 +4
|
/test latest-mesh |
Rebased and istio version bumped. @evankanderson any thoughts about #1085 (comment) and #1085 (comment)? For the latter, what is the plan to move/migrate stuff from |
This Pull Request is stale because it has been open for 90 days with |
/remove-lifecycle stale |
13c76e4
to
a5c4941
Compare
Co-authored-by: Kenjiro Nakayama <nakayamakenjiro@gmail.com>
Co-authored-by: Kenjiro Nakayama <nakayamakenjiro@gmail.com>
51e94ae
to
9222267
Compare
9222267
to
28dd4c5
Compare
/test latest |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nak3, ReToCode The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@dprotaso do you want to take a look as well? |
/unhold |
bumping knative.dev/net-istio 8aa5561...be4f06e: > be4f06e Revert knative-extensions/net-istio#1085 (# 1344) Signed-off-by: Knative Automation <automation@knative.team>
bumping knative.dev/net-istio 8aa5561...be4f06e: > be4f06e Revert knative-extensions/net-istio#1085 (# 1344) Signed-off-by: Knative Automation <automation@knative.team>
bumping knative.dev/net-istio 8aa5561...be4f06e: > be4f06e Revert knative-extensions/net-istio#1085 (# 1344) Signed-off-by: Knative Automation <automation@knative.team>
Changes
system-internal-tls
innet-istio
Things to discuss
config/700-istio-secret.yaml
is necessary because the CA secrets needs to be inistio-system
namespace for istio to pick it up. It's currently the only way to get the CA there. This is why https://docs.google.com/document/d/1YdcdBVg_zpT4WSNRsWlihut5JuLddOTIggFvLni3A28/edit?disco=AAAAtaDADjo proposes to add the CA toKIngress
net-kourier
. If we do Provide HTTPS for cluster.local domains knative/serving#13472 this handling can be dropped (here and innet-kourier
andnet-contour
)http2
is currently based on service naming, which is not ideal. Thus https://docs.google.com/document/d/1YdcdBVg_zpT4WSNRsWlihut5JuLddOTIggFvLni3A28/edit?disco=AAAAtaDADjo also proposes to add the upstream protocol to theKIngress
resource to avoid this in the future.Release Note
No release notes yet, as this is still an internal/alpha feature.
Docs
No docs yet, as this still an internal/alpha feature.
/kind enhancement
Fixes #1063