Skip to content
This repository has been archived by the owner on Apr 30, 2024. It is now read-only.

http01 challenge must support K-Network-Probe #44

Open
mattmoor opened this issue Jul 25, 2020 · 10 comments
Open

http01 challenge must support K-Network-Probe #44

mattmoor opened this issue Jul 25, 2020 · 10 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@mattmoor
Copy link
Contributor

In order to assess readiness, we expect services included in kingress to support the K-Network-Probe handshake.

See related issue for net-http01: knative-extensions/net-http01#48

@mattmoor
Copy link
Contributor Author

cc @ZhiminXiang

@ZhiminXiang
Copy link

/assign

@ZhiminXiang
Copy link

The difference btw net-certmanager and net-http01 is that the service for serving HTTP01 challenge is not controlled by Knative. It is set up by cert-manager.

I am gonna look into cert-manager and see how we can add the logic into cert-manager.

@mattmoor
Copy link
Contributor Author

mattmoor commented Aug 6, 2020

Alternately we could create a way in our dataplane contract to express that certain services do not need (or don't support) probing.

mattmoor added a commit to mattmoor/net-contour that referenced this issue Aug 6, 2020
Right now net-contour doesn't properly support certmanager-based http01 challenges because it expects all references services to adhere to the dataplane contract around probing.

Related: knative-extensions/net-certmanager#44
@ZhiminXiang
Copy link

Alternately we could create a way in our dataplane contract to express that certain services do not need (or don't support) probing.

SGTM. This could be a workaround.

knative-prow-robot pushed a commit to knative-extensions/net-contour that referenced this issue Aug 6, 2020
Right now net-contour doesn't properly support certmanager-based http01 challenges because it expects all references services to adhere to the dataplane contract around probing.

Related: knative-extensions/net-certmanager#44
@ZhiminXiang
Copy link

Just for record, the Ingress prober implementation of Istio is based on hosts of Ingress. See the code here. So It just probes host without path. Therefore, cert-manager currently can work with net-Istio.

I think we should still pursue wrapping the http01 challenge service in the cert-manager side. Once that lands, we can extend the prober to support probing path which is more accurate.

@mattmoor
Copy link
Contributor Author

It's either our dataplane contract or it's not.

cc @tcnghia since he was considering doing the same thing I did in net-contour in net-istio.

mattmoor added a commit to mattmoor/docs that referenced this issue Sep 11, 2020
All of the known remaining issues with Contour have been resolved, and I've been carefully monitoring testgrid and digging into any 503s (or other dataplane related failures).

As of me writing this:
1. The only failure in the net-contour testgrid is due to its workaround for knative-extensions/net-certmanager#44, which shouldn't practically manifest in the context of Serving.
2. The only failures in the contour leg on Serving testgrid are due to infrastructure (Go, etcd, GKE, resource exhaustion)

I will continue to track testgrid carefully as we head towards 0.18, but at present it is likely as solid as any of our ingress options.
knative-prow-robot pushed a commit to knative/docs that referenced this issue Sep 13, 2020
All of the known remaining issues with Contour have been resolved, and I've been carefully monitoring testgrid and digging into any 503s (or other dataplane related failures).

As of me writing this:
1. The only failure in the net-contour testgrid is due to its workaround for knative-extensions/net-certmanager#44, which shouldn't practically manifest in the context of Serving.
2. The only failures in the contour leg on Serving testgrid are due to infrastructure (Go, etcd, GKE, resource exhaustion)

I will continue to track testgrid carefully as we head towards 0.18, but at present it is likely as solid as any of our ingress options.
@github-actions
Copy link

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 11, 2020
@mattmoor
Copy link
Contributor Author

/lifecycle frozen

@ZhiminXiang any update?

@knative-prow-robot knative-prow-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Nov 11, 2020
@dprotaso
Copy link
Contributor

/unassign @ZhiminXiang

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

4 participants