Network Proxy KEP. #872

cheftako · 2019-03-05T02:45:40Z

Adding KEP based on https://goo.gl/qiARUK.
Plan to add support for a network proxy between Kubernetes API Server and cluster/nodes.
Supports the removal of the deprecated SSH Tunnel system.
Adds supports for certain security features.

cheftako · 2019-03-05T02:46:34Z

/assign @calebamiles @anfernee @deads2k @lavalamp @bowei

keps/sig-api-machinery/20190226-network-proxy.md

justinsb

Looks great - nit picks but I think the design is sound

keps/sig-api-machinery/20190226-network-proxy.md

justinsb · 2019-03-07T15:22:04Z

keps/sig-api-machinery/20190226-network-proxy.md

+Each connectivity proxy allows secure connections to one or more cluster networks. 
+Any network addressed by a connectivity proxy must be flat. 
+Currently the only mechanism for handling overlapping IP ranges in Kubernetes is the Proxy. 
+As we are passed the proxy there would need to be a non Kubernetes mechanism 


This was not clear to me. I think you mean "the Cluster Network must have a mechanism to reach the proxy, and the the KAS must have a mechanism to reach the proxy. This would be configured as part of cluster creation, not by Kubernetes itself" (or something like that?)

keps/sig-api-machinery/20190226-network-proxy.md

justinsb · 2019-03-07T15:39:07Z

keps/sig-api-machinery/20190226-network-proxy.md

+in a “legacy” mode or as a fallback. It also allows for very simple clusters 
+which do not need the concept of network segregation to be run 
+without the overhead (either in extra hop latency or configuration complexity) 
+of using the connectivity proxy.


Would this be the implicit configuration if proxies were not configured? (Less secure, but I'm guessing so for compatibility)

I think so yes.

keps/sig-api-machinery/20190226-network-proxy.md

justinsb · 2019-03-07T15:42:36Z

keps/sig-api-machinery/20190226-network-proxy.md

+- **Admission Webhooks**
+Admission webhooks can either be destined for a service or a URL. 
+If they are destined for a service then the service rules apply. 
+If they are destined for a URL then we will use the ‘master’ NetworkContext. 


Can I not address a service by URL?

I have never tried addressing a K8s service via the URL. If someone wants to send to a K8s service, they should use the service configuration. Given that the proxy used in these two examples will be different, they need to use the correct configuration.

keps/sig-api-machinery/20190226-network-proxy.md

Added details including prototype grpc spec. Added NetworkContext definition. Added detailed explanations of use cases. Includes feedback from Lavalamp, Justinsb and Anfernee. More feedback from lavalamp and justinsb.

mikedanese · 2019-03-10T05:48:49Z

keps/sig-api-machinery/20190226-network-proxy.md

+// side of the tunnel. The format is inspired by golang's net interface
+// https://golang.org/pkg/net/#Dial 
+message DialRequest {
+    // network representing a named network. "Tcp" is the only supported


Do you plan to support more than just TCP?

Right, maybe UDP, not the highest priority at this point of time tho.

The API server doesn't do anything with UDP today. For a while now, we've discussed breaking the proxy functionality out of the API server. I would be pretty hesitant to add more functionality at this point.

exactly, to be clear, we don't have a plan to support UDP. the field is there just for the sake of extensibility. it's okay to me to remove it and assume all traffic is tcp, but in future if there is need, there will be a proto change.

Adding a field later that defaults to tcp is a backwards compatible change.

mikedanese · 2019-03-10T05:49:58Z

keps/sig-api-machinery/20190226-network-proxy.md

+    // the number is kept unchanged across the proxies, and copied to DialResponse
+    // from the other side of the tunnel. The number cannot be reused across 
+    // different DialRequests.
+    bytes random = 3;


How is this used? Why is the grpc stream id not sufficient?

This is to multiplex more than one connections through the same grpc stream. Once a grpc stream is established, packets can flow back and forth between both ends of the stream. There also could be multiple dial requests sent out at the same time, random is used to match between response and request.

I guessed that, but why is it useful to multiplex connections over a single grpc stream? Grpc streams are already multiplexed over a single tcp connection.

I see what you mean. Good question. Actually there is another option to avoid this, but it would be 2 method calls. Mostly because the grpc stream doesn't allow you to specify a destination. so you have to Dail then Connect. It's similar (not exactly) to socket, where you need to call socket to get a fd then connect to get another one for streaming.

service ProxyService { // DialRequest and DialResponse is the same, but without random. rpc Dial(req DialRequest) DialResponse {} rpc Connect(stream Packet) (stream Packet) {} }

This potentially moves the stream control out, and we probably need another method Close as well. The problem of this approach is that it's hard to define the order of multiple data and control flows in different serving threads. e.g. say when a close request and data comes in at the same time, it's hard to tell who's coming first. The right behavior is pretty much hard to define. While in the same stream, it's all sequential, then it's just a matter of whoever arrives first.

The problem of this approach is that it's hard to define the order of multiple data and control flows in different serving threads. e.g. say when a close request and data comes in at the same time, it's hard to tell who's coming first. The right behavior is pretty much hard to define. While in the same stream, it's all sequential, then it's just a matter of whoever arrives first.

Assume packets arrive reliably and in order, send dial parameters in a message extension or header and you have yourself a drop in replacement for net.Dial with all the hard stuff handled by the lower layers :)

mikedanese · 2019-03-10T05:58:20Z

keps/sig-api-machinery/20190226-network-proxy.md

+service ProxyService {
+    // Proxy connects to a remote address by stream id, and establish
+    // a bi-directional stream of packet exchange.
+    rpc Proxy(stream Packet) returns (stream Packet) {}


Why wouldn't a simpler interface work? e.g.

rpc Proxy(stream Bytes) (stream Bytes) {}

With parameters like IP passed in headers or a request extension?

Maybe it could. I thought stream as a way of a reliable or unreliable transport, like IP network. then I thought of packet as a TCP/UDP packet, where the functionality is self-contained, not relying on anything else.

It depends on if you ever want to support more than the https://godoc.org/net#Conn interface. If net.Conn (which supports UDP connections) is sufficient then this is a massive simplification.

functionality is self-contained, not relying on anything else.

With the downside that we have to reimplement stream reassembly, queue discipline/priority, etc... all the things that are already handled by http/2 and TCP.

mikedanese · 2019-03-10T06:01:09Z

Why would we go this route vs implementing it outside of the API server with tunneling software and a TAP device?

keps/sig-api-machinery/20190226-network-proxy.md

andrewsykim · 2019-03-11T21:45:45Z

keps/sig-api-machinery/20190226-network-proxy.md

+apiVersion: connectivityservice.k8s.io/v1alpha1
+kind: ConnectivityServiceConfiguration
+connectionService:
+  name: Master


Thoughts on s/Master/ControlPlane?

(realizing now that the name of the resource is arbitrary)

This connectionService and the etcd connectionService may not be as arbitrary as the rest.

keps/sig-api-machinery/20190226-network-proxy.md

cheftako · 2019-03-12T21:58:18Z

@mikedanese I do not believe this can be implemented completely outside of the KAS. The network context is fundamental to what is happening here and would require we export that data to hand it off. We know that two requests for the same IP should be routed to different machines based on the network context. The current design is trying to acknowledge this requirement while minimizing how much needs to change inside of the KAS.

dims · 2019-03-13T12:05:48Z

@cheftako sorry for a dumb question - how does the kubelet reach the api server (during kubelet startup)? interested both in the current SSH based scenario as well as after this KEP is implemented

cheftako · 2019-03-13T17:06:03Z

@dims Not a dumb question at all, though somewhat orthogonal. I'm assuming here that you are referring to cluster-side initiated requests. (Could be Kubelet, a controller/webhook etc running on a managed node, ...) For all these cases the KAS has a publicly advertised IP address (this may be to a LB in front of a set of HA KASs or the address of a single KAS). The cluster-side components should be making HTTPS requests and providing some sort of authentication/authorization materials to the KAS. None of the cluster-side initiated requests go over the SSH Tunnel today. This KEP does not cover switching any of these requests to go over the Network Proxy.

It would theoretically be possible to switch cluster-side initiated requests to go over the Proxy Tunnel. That is not in scope of this KEP. It also has a problem of how you initiate that tunnel (again not in scope of this KEP).

dims · 2019-03-13T17:15:36Z

Ack thanks @cheftako we could add that info in the "out of scope" section :)

mvladev · 2019-03-13T19:24:39Z

keps/sig-api-machinery/20190226-network-proxy.md

+  connection:
+    type: grpc
+    url: grpc://1.2.3.4:5678
+    caBundle: file1.ca


In apiregistration/v1's APIService and other webhooks, this is a PEM encoded CA bundle.
Maybe it's better to keep it the same?

This was always intended to be a pem ENCODED CA bundle.

mvladev · 2019-03-13T19:36:01Z

keps/sig-api-machinery/20190226-network-proxy.md

+
+One motivation for network proxy is providing a mechanism to secure 
+https://groups.google.com/d/msg/kubernetes-security-announce/tyd-MVR-tY4/tyREP9-qAwAJ. 
+This, in conjunction with a firewall or other network isolation, fixes the security concern. 


What about authentication / authorization? How does the proxy validates that it's receiving traffic from the K8S API server? Maybe the same mechanism as in /pull/658 can be used here?

Authentication added. Modeling after the aggregator flags on the api-server. Authorization is left as an exercise to the proxy writer.

keps/sig-api-machinery/20190226-network-proxy.md

tallclair

I'm still a little confused about how the proxy <-> cluster (node) network connection is established.

tallclair · 2019-03-22T22:47:26Z

keps/sig-api-machinery/20190226-network-proxy.md

+It listens on a port for gRPC connections from the KAS. 
+This port would be for forwarding traffic to the appropriate cluster. 
+It should have an administrative port speaking https. 
+The administrative port serves the liveness probe and metrics. 


Note that liveness probes don't currently support mutual TLS.

Good point. My thought was that as this is a third port (master side being the first and node/cluster/agent side being the second, both of which should have mTLS) that its restrictions could be different. I was also thinking that it would probably only be listening on localhost. If you feel that it still needs mTLS I can seperate the probe ports from the rest of the admin ports.

tallclair · 2019-03-22T22:51:13Z

keps/sig-api-machinery/20190226-network-proxy.md

+## Proposal
+
+We will run a connectivity proxy inside the master network. 
+The connectivity proxy exposes a gRPC interface to the KAS. 


I don't know much about network proxies, but is there not a solid opensource solution that already exists? Envoy comes to mind as something that might be able to perform the required functions (https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/tcp_proxy)

I actually looked at this. It supports tunneled tcp over h2 connection pools, which is essentially what we would be doing, but it doesn't support reverse tunnels yet. It's probably something that could be added though.

tallclair · 2019-03-22T22:53:49Z

keps/sig-api-machinery/20190226-network-proxy.md

+- **Admission Webhooks**
+Admission webhooks can be destined for a service or a URL. 
+If destined for a service then the service rules apply (send to 'cluster'). 
+If destined for a URL then we will use the ‘master’ NetworkContext. 


That seems like a security risk if users shouldn't have access to the master network context.

Access to the master network via a URL on an admission webhook is an already existing behavior today, even when SSH Tunnnels have been configured.
Several features/customers rely on this behavior to access cloud provider specific webhooks running on some form of WebhookManager.
So as it stands it is no worse than today and forwarding this traffic to the node network would break those features.
In addition the cloud providers can add filters to the master proxy to prevent access to things like etcd.
Lastly the traffic being sent is not arbitrary. The requests are admission requests formed by the API Server itself. We should not rely on being well formed admission requests but it does provide a last line of defense if something does get by the filter.

tallclair · 2019-03-22T22:54:40Z

keps/sig-api-machinery/20190226-network-proxy.md

+Aggregated API Servers can be destined for a service or a URL. 
+If destined for a service then the service rules apply. 
+If destined for a URL then we will use the ‘master’ NetworkContext.
+- **Authentication, Authorization and Audit Webhooks**


Dynamic audit webhooks should be treated similarly to dynamic admission controllers.

gRPC Change

keps/sig-api-machinery/20190226-network-proxy.md

bowei · 2019-03-28T18:40:10Z

keps/sig-api-machinery/20190226-network-proxy.md

+
+// Payload defines a TCP payload.
+message Payload {
+  bytes data = 1;


we don't have any provision for errors?

Working through this item. We expect to have more details on this later.

keps/sig-api-machinery/20190226-network-proxy.md

krousey · 2019-04-01T15:36:58Z

keps/sig-api-machinery/20190226-network-proxy.md

+## Proposal
+
+We will run a connectivity proxy inside the master network.
+The connectivity proxy exposes a gRPC interface to the KAS.


It's my understanding that the current SSH tunnel implementation just replaces the http.Transport.Dial function member. Would it be possible to have something that uses a standard HTTP/HTTPS proxy by replacing the http.Transport.Proxy function member and not define a custom gRPC service? I think using an existing standard would be preferred and make existing proxies usable.

If there's a technical reason why HTTP/HTTPS proxies are insufficient, can we document why in the "Alternatives Considered" section?

I had the same question... I think it was discussed in the original doc (https://docs.google.com/document/d/1djkroHhbhdZATdtZ3UBRxCR0TG92kKCrTmHib86soE4/edit#heading=h.quk4manl97c) but I agree it should be hoisted into this doc

+1 and hopefully support for socks proxies too. Have struggled with kubectl's lack of socks support for a while.

@liggitt That only seems to address SOCKS5 proxies. Do the same limitations apply to HTTPS CONNECT proxies? Do we need the general connectivity of SOCKS5? I was under the impression that all connections were HTTP 2 and then hijacked if more flexibility is needed.

@cheftako can confirm, but my understanding was that wanting to run mutual auth (e.g. mTLS)--both to the proxy and through the proxy--ruled out everything he looked at.

@kfox1111 this KEP will not affect kubectl at all, it is only about apiserver.

HTTP connect proxy is an interesting option. It seems to work, but will be non-extensible. It does not really have a mechanism for propagating errors/information about the stream and is much less transparent/debuggable (the RFC itself is somewhat underwhelming in specification).

I would try to avoid doing very funky things with network namespaces and interfaces. These implementations end up being boxed in by what can be done with Linux and quite obscure config-wise. They can also be very had to debug.

Looking into using the HTTP Connect proxy. Definitely a simpler solution. A little concerned with A) its ability to multiplex. Will proto-type and see if we have scaling issue for blow up the number of connections. Increasing reliance on admission webhooks make this more of a concern. B) Not clear how varying failure/error cases such as EOF and proxied connection closes will work on the tunnel. Will add some info on this.

I would try to avoid doing very funky things with network namespaces and interfaces. These implementations end up being boxed in by what can be done with Linux and quite obscure config-wise. They can also be very had to debug.

If Bowei feels this way too, can we lay this idea (of using multiple interfaces in a specially configured network namespace) to rest as a rejected alternative?

These implementations end up being boxed in by what can be done with Linux and quite obscure config-wise.

My impression was that a TUN / TAP interface can do anything at all — it's just a userspace program that pushes and pulls packets from the corresponding virtual interface.

They can also be very had to debug.

No argument there :)

I think it's important to minimize the size of the change in Kubernetes necessary to support this use case. Whether that's by using an existing HTTP proxy or by using Linux network interfaces doesn't make a big difference.

Looking at the organizational affiliations of everyone participating on the KEP PR, it seems clear that this is, like SSH tunnels, a feature where everyone but Google is going to be choosing the default option. Minimizing the burden on upstream Kubernetes makes sure that we won't be reading another KEP in a few years time with a justification like

They complicate KAS code and only one cloud provider implemented them. After a year of deprecation time, they will be removed in an upcoming release.

So, lets back up a little bit to some higher level questions. What is going to be the common case?
kubeadm deployed cluster? The proxy really needs to be implemented on all clusters to solve CVE-2018-1002105?

So, deployment of the proxy, whatever the default is, needs to be easy to deploy as part of kubeadm, and work in the 1 and 3 controller configurations that its trying to support?

How would the proxy be restricted just to the external network and not any internal networks?

krousey · 2019-04-01T22:03:24Z

keps/sig-api-machinery/20190226-network-proxy.md

+
+Delete the SSH Tunnel/Node Dialer code from Kube APIServer.
+Enable admins to fix https://groups.google.com/d/msg/kubernetes-security-announce/tyd-MVR-tY4/tyREP9-qAwAJ.
+Allow isolation of the Control network from the Cluster network.


I don't want to pile on here, but could this also allow the deprecation of https://github.com/kubernetes/kubernetes/blob/d1031b18fc83146dd8418c17df289d09d10d29e5/staging/src/k8s.io/apimachinery/pkg/util/net/http.go#L273-L309

Or is this used by more than the API server?

Agree that this is a further benefit for doing this work.

keps/sig-api-machinery/20190226-network-proxy.md

khenidak · 2019-04-03T17:17:05Z

keps/sig-api-machinery/20190226-network-proxy.md

+- **Connectivity service** A component built into the KAS which provides a golang dialer for outgoing connection requests.
+The dialer provided depends on NetworkContext information.
+- **Connectivity proxy** The proxy that runs in the master network.
+It has a secure channel established to the cluster network.


following the same line of thought of nodes spanning multiple non-interconnected networks. it has a secure channel established to cluster network, or cluster networks?

Please see above. In addition for cases like this I think we are likely to want to add some level of metadata on the request. (Eg. node name or failure domain/zone) So getting to the right network could either be by more fine grained ConnectivityServiceConfiguration or it would be that the proxy has enough metadata to make the call. Again though I think this is more part of beta than alpha.

khenidak · 2019-04-03T17:30:39Z

keps/sig-api-machinery/20190226-network-proxy.md

+NetworkContext could be extended to contain more contextual information.
+This would allow smarter routing based on the k8s object KAS is processing
+or which user/tenant tries to initiate the request, etc.
+


How are we going to do load balancing api-server -> connectivity proxy ?
Option 1: Urls becomes a list, users can run the proxy on per master node bases or 2 or just one. That means the api server needs to maintain rr state of last connection
Option 2: Forcing the user to run an internal load balancer.

I vote option 1

never mind. below you are asserting same node as api-server.

khenidak · 2019-04-03T17:39:17Z

keps/sig-api-machinery/20190226-network-proxy.md

+The liveness probe prevents a partially broken cluster
+where the KAS cannot connect to the cluster. This port also serves
+pprof debug commands and monitoring data for the proxy.
+


early on the discussion was, allow the api-server to serve requests even if the proxy service. How will this work if an api-server instance is healthy yet the connectivity proxy isn't? We will get weird behavior where some api server calls succeed and some fail depending on which instance picked up the request and the type of that particular request. I believe we either find a way to load balance api-server --> connectivity proxy or we tie the health of api-server to the proxy by design (this will introduce a catch-22 situation where all nodes are unhealthy taking proxies down, and accordingly api-server).

Good point. A few thoughts. 1) Proxy service should have a liveness check which means the kubelet shoudl be getting it to recover. 2) The proxy service is significantly simpler in scope, responsibility and code than the API Server, so it should be easier to make it more resilient. 3) In a HA environment we should absolutely consider having the API Servers readiness probe dependent on the proxy and thus control which API servers get traffic. 4) The design deliberately suggests configuration options rather than mandating them. A provider is welcome to load-balance api-server to connectivity proxy.

I agree it makes sense to operate the proxy as an HA LB service. I don't think the default setup needs to do that.

It's important to note that if this proxy is down, the cluster is only partially broken. Only master-> node calls stop working. Which is not a large fraction of requests. So, I don't actually agree that apiserver's readiness probe should depend on the proxy's readiness: that would make a minor problem into a cluster-breaking problem.

So, I don't actually agree that apiserver's readiness probe should depend on the proxy's readiness: that would make a minor problem into a cluster-breaking problem.

+1, that sounds like a recipe for cascading failure

Thanks. I Agree, let us decouple the health of api-server from the proxy.

The HA scenario is quite interesting. i would love to see the details around the proposed nodes->proxy connectivity as requested in #872 (comment)

khenidak · 2019-04-03T17:40:53Z

keps/sig-api-machinery/20190226-network-proxy.md

+This will add an extra process hop to our main scaling axis.
+We will scale test the impact and publish the results. As a precaution
+we will add an extra network configuration 'etcd' separate from ‘master’.
+Etcd requests can be configured separately from the rest of 'master'.


What is the use case for that?

I see two use cases. 1) By dictating what is supposed to be etcd destined traffic you can configure that proxy as the only one with access to etcd. This can be another layer of protection for etcd from things like our proxy sub resources. 2) Etcd is a primary dimension of scalability. This allows us to do things like bypass proxy specifically for etcd traffic if you are running close to the edge.

keps/sig-api-machinery/20190226-network-proxy.md

khenidak · 2019-04-03T17:50:40Z

keps/sig-api-machinery/20190226-network-proxy.md

+- **ImagePolicyWebhook**
+The image policy webhook uses a kube config file to determine destination.
+Given that we use a ‘master’ NetworkContext.
+- **KMS GRPC Service**


:-) just a kudos on remembering this one, thanks!

Thanks 😃

Updated proxy kep. Further details. Factored in naming and formating changes. Cahnges suggested by dcbw, mvladev, dims, andrewsykim, mikedanese, justinsb, anfernee Added HTTP Connect option. Also fixed network name. Fixed approver/reviewer lines. Elaborated on some/all nodes for cluster network definition. Fixed spelling mistake.

deads2k · 2019-04-05T15:16:26Z

I understand why we want the kube-apiserver intelligent enough to choose different proxies for different destinations and the description of how to choose in the kube-apiserver and the subdivisions provided lgtm.

I do not know enough to comment on the actual proxy and networking configuration being proposed here. I encourage those reviewers to choose a solution that has off-the-shelf, opensource implementations.

kfox1111 · 2019-04-05T15:26:07Z

I encourage those reviewers to choose a solution that has off-the-shelf, opensource implementations.

+1. and I'd also suggest that whatever the default chosen should be very easy to deploy and maintain. kubeadm should be able to easily plop down the proxy and manage it.

bowei · 2019-04-08T17:49:58Z

@cheftako @anfernee you have my approval for the proposal regarding general (don't block on me for getting the other approvals)

lavalamp · 2019-04-08T22:05:43Z

Looks like we have sign-off from @deads2k and @bowei for their respective parts of the system. Perhaps we can merge this and clear up any other feedback when we're ready to set the status to implementable?

/lgtm
/approve

I'll keep it open for just a bit longer just in case someone wants to argue with that assessment :)
/hold

andrewsykim · 2019-04-09T04:31:39Z

/lgtm

k8s-ci-robot · 2019-04-09T04:31:49Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewsykim, cheftako, lavalamp

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:

~~keps/sig-api-machinery/OWNERS~~ [lavalamp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

lavalamp · 2019-04-09T17:30:13Z

/hold cancel

mcrute · 2019-04-24T17:58:15Z

Thanks @cheftako! We're really excited at AWS to see this start to take shape and look forward to helping push this forward to implementation.

k8s-ci-robot requested review from deads2k and lavalamp March 5, 2019 02:45

k8s-ci-robot assigned anfernee, bowei, calebamiles, deads2k and lavalamp Mar 5, 2019

anfernee approved these changes Mar 5, 2019

View reviewed changes

keps/sig-api-machinery/20190226-network-proxy.md Outdated Show resolved Hide resolved

justinsb reviewed Mar 7, 2019

View reviewed changes

Network Proxy KEP.

8c1df8e

Added details including prototype grpc spec. Added NetworkContext definition. Added detailed explanations of use cases. Includes feedback from Lavalamp, Justinsb and Anfernee. More feedback from lavalamp and justinsb.

cheftako force-pushed the master branch from f527175 to 8c1df8e Compare March 8, 2019 06:48

cheftako changed the title ~~[WIP] Network Proxy KEP.~~ Network Proxy KEP. Mar 8, 2019

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 8, 2019

mikedanese reviewed Mar 10, 2019

View reviewed changes

andrewsykim reviewed Mar 11, 2019

View reviewed changes

keps/sig-api-machinery/20190226-network-proxy.md Outdated Show resolved Hide resolved

andrewsykim reviewed Mar 11, 2019

View reviewed changes

keps/sig-api-machinery/20190226-network-proxy.md Outdated Show resolved Hide resolved

andrewsykim reviewed Mar 11, 2019

View reviewed changes

keps/sig-api-machinery/20190226-network-proxy.md Show resolved Hide resolved

dims mentioned this pull request Mar 13, 2019

remove deprecated ssh tunneling functionality in API Server kubernetes/kubernetes#75330

Closed

dixudx mentioned this pull request Mar 13, 2019

WIP: Add a kubelet /podProxy endpoint kubernetes/kubernetes#75329

Closed

mvladev reviewed Mar 13, 2019

View reviewed changes

andrewsykim mentioned this pull request Mar 20, 2019

API Server Network Proxy: GA kubernetes/cloud-provider#23

Open

dcbw reviewed Mar 21, 2019

View reviewed changes

keps/sig-api-machinery/20190226-network-proxy.md Outdated Show resolved Hide resolved

tallclair reviewed Mar 22, 2019

View reviewed changes

anfernee and others added 2 commits March 25, 2019 16:21

gRPC Change

495ddf0

Merge pull request #1 from anfernee/kep

9face4e

gRPC Change

bowei reviewed Mar 28, 2019

View reviewed changes

krousey reviewed Apr 1, 2019

View reviewed changes

khenidak requested changes Apr 3, 2019

View reviewed changes

cheftako force-pushed the master branch from f2b99ae to a4c0ca5 Compare April 4, 2019 17:16

cheftako force-pushed the master branch from a4c0ca5 to 2178da3 Compare April 4, 2019 17:23

k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Apr 8, 2019

k8s-ci-robot assigned andrewsykim Apr 9, 2019

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 9, 2019

k8s-ci-robot merged commit 8425d7b into kubernetes:master Apr 9, 2019

Network Proxy KEP. #872

Network Proxy KEP. #872

Conversation

cheftako commented Mar 5, 2019

cheftako commented Mar 5, 2019

justinsb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anfernee Mar 11, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikedanese Mar 10, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikedanese Mar 20, 2019 • edited Loading

Choose a reason for hiding this comment

mikedanese commented Mar 10, 2019

Choose a reason for hiding this comment

andrewsykim Mar 11, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cheftako commented Mar 12, 2019

dims commented Mar 13, 2019

cheftako commented Mar 13, 2019

dims commented Mar 13, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tallclair left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deads2k commented Apr 5, 2019

kfox1111 commented Apr 5, 2019

bowei commented Apr 8, 2019

anfernee Mar 11, 2019 •

edited

Loading

mikedanese Mar 10, 2019 •

edited

Loading

mikedanese Mar 20, 2019 •

edited

Loading

andrewsykim Mar 11, 2019 •

edited

Loading