iptables-based portmapping plugin #1

squeed · 2017-03-13T18:40:17Z

This is a fairly standard iptables-based portmapping plugin. It supports ipv4 and ipv6.

This replaces the proposed plugin in the cni repository.

thockin

Something we do in kubernetes that this is not doing: We open and bind() the actual port on the host. This means that anyone who tries to use that port (via hostNetwork, a simple process, or whatever) will get EBUSY instead of actually binding but not working.

To do this, we'd need a long-running process to collect the ports or else a small long-running process per port-forward. It's a trivial program, though the overhead of Go might be bad for this. Easy to do in C...

Or we can decide this is not worth doing. It's sort of a hassle...

thockin · 2017-03-14T22:20:00Z

plugins/portmap/README.md

+8080 and 8043 on the host forwarded to ports 80 and 443 in the container, the 
+rules look like this:
+
+`PREROUTING`, `OUTPUT` chains:


Something we discovered in Kubernetes - this expression is looser than we really want. This will match any address in the local routing table, whereas I think we only want addresses that are actually bound to interfaces. The delta here is things like load-balancer VIPs on GCE.

The solutions that is pending is to loop over all interfaces and expand them into a set of exact-IP matches. It is sort of awful because, at least in theory, this can change, so it needs to be refreshed periodically. I don't know how else to express this condition, but I am open to ideas.

An alternative would be to document this as "must be the last rule in the chain" but that feels very brittle in the face of collaboration users of iptables.

Interesting. I'd always thought the local routing table was essentially read-only, but a quick experiment shows it's not (neat!).

Question: are you just concerned about performance, or is it expected that traffic from these interfaces are not forwarded? In a (non-k8s?) case, is it desirable that a GCE vip would be forwarded to a container? A quick glance at the documentation makes this at least seem plausible.

A few thoughts on possible solutions:

Have a daemon that listens to netlink messages and updates a linux ipset with the list of local ifs

Add a configuration option to the plugin to add conditions to the second-level entry rule. Then the administrator could exclude either specific CIDRs, devgroups, or ipsets

Write the port reservation daemon, then match on socket (this is medium sketchy)

Either way, I'm thinking about adding a portset (via ipset(8)) to the top-level entry rule for improved performance.

In the interest of progressing this PR, why don't we start by implementing this the way it's written today (any addresses in the local routing table) and then follow up with a fix using ipsets?

It wouldn't be a regression in behavior since that's how k8s behaves today, and so long as we have a plan for how to fix in a second release then I think I'm OK with it.

An alternative would be to document this as "must be the last rule in the chain" but that feels very brittle in the face of collaboration users of iptables

Yeah it does, but maybe it's fine as a first step?

thockin · 2017-03-14T22:27:09Z

plugins/portmap/README.md

+chain.
+
+`POSTROUTING`:
+- `-s 127.0.0.1 ! -d 127.0.0.1 -j CNI-HOSTPORT-SNAT`


should be 127.0.0.0/8 for both?

thockin · 2017-03-14T22:29:48Z

plugins/portmap/README.md

+- `-j CNI-SN-xxxxx`
+
+`CNI-SN-xxxxx`:
+- `-p tcp -s 127.0.0.1 -d 172.16.30.2 --dport 80 -j MASQUERADE`


Do we need the -s at all? It was a pre-condition to end up here in the first place. Do we even need the destination and the port? Is there any case where the initial condition (-s localhost -d not-localhost) doesn't need masquerade?

We definitely don't need the -s. I added the -d and --dport so that the minimal possible set of traffic from 127.0.0.1 is allowed out. Otherwise this is a nasty potential firewall bypass owing to the fact that route_localnet is enabled.

squeed · 2017-03-15T16:35:29Z

We open and bind() the actual port on the host.

I thought about doing this, with a helper daemon à la DHCP, but decided against the trouble. If you think it's a worthy idea, it could still be done. It can also be added later.

thockin · 2017-03-15T16:46:58Z

I think it is closing a real gap where users can get confused, but it is a relatively slim gap. Obviously, if it is easy, we should do it. How easy is easy enough? Also, yes, it can be additive

…

On Wed, Mar 15, 2017 at 9:35 AM, Casey Callendrello < ***@***.***> wrote: We open and bind() the actual port on the host. I thought about doing this, with a helper daemon à la DHCP, but decided against the trouble. If you think it's a worthy idea, it could still be done. It can also be added later. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVF8Gwszv20kgT-MicMCgZs8Qjpsiks5rmBNRgaJpZM4MbqAA> .

thockin · 2017-03-17T20:03:37Z

On Wed, Mar 15, 2017 at 10:48 AM, Casey Callendrello ***@***.***> wrote: @squeed commented on this pull request. ________________________________ In plugins/portmap/README.md: > +## Rule structure +The plugin sets up two sequences of chains and rules - one "primary" DNAT +sequence to rewrite the destination, and one additional SNAT sequence that +rewrites the source address for packets from localhost. The sequence is somewhat +complex to minimize the number of rules non-forwarded packets must traverse. + + +### DNAT +The DNAT rule rewrites the destination port and address of new connections. +There is a top-level chain, `CNI-HOSTPORT-DNAT` which is always created and +never deleted. Each plugin execution creates an additional chain for ease +of cleanup. So, if a single container exists on IP 172.16.30.2 with ports +8080 and 8043 on the host forwarded to ports 80 and 443 in the container, the +rules look like this: + +`PREROUTING`, `OUTPUT` chains: Interesting. I'd always thought the local routing table was essentially read-only, but a quick experiment shows it's not (neat!).

Yeah, I learned this through GCE's tricks.

Question: are you just concerned about performance, or is it expected that traffic from these interfaces are not forwarded? In a (non-k8s?) case, is it desirable that a GCE vip would be forwarded to a container? A quick glance at the documentation makes this at least seem plausible.

GCE by default assigns VIPs as local addresses. Kubernetes on GCE instead traps those VIPs and redirects to containers. Overall this works really well, but now we have 2 different entities - CNI plugin and kube-proxy - writing iptables rules that potentially overlap. We can either try to ensure ordering of rules from most-specific to least specific, or we can refine our definition of what we trap so that ordering is not a factor. I obviously prefer the latter, but it's not perfect, either.

A few thoughts on possible solutions: Have a daemon that listens to netlink messages and updates a linux ipset with the list of local ifs Add a configuration option to the plugin to add conditions to the second-level entry rule. Then the administrator could exclude either specific CIDRs, devgroups, or ipsets Write the port reservation daemon, then match on socket (this is medium sketchy) Either way, I'm thinking about adding a portset (via ipset(8)) to the top-level entry rule for improved performance.

I would not focus on performance yet. Let's figure out what we think is the correct semantic.

thockin · 2017-03-17T20:04:57Z

I don't understand the firewall bypass? If this was (implicitly, before jumping to this rule) `-s 127.0.0.0/8` and explicitly `! -d 127.0.0.0/8 -J MASQUERADE`, what am I missing? One rule to catch it all..

…

On Wed, Mar 15, 2017 at 10:56 AM, Casey Callendrello < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In plugins/portmap/README.md <#1 (comment)> : > +### SNAT +The SNAT rule rewrites (masquerades) the source address for connections from +localhost. If this rule did not exist, a connection to `localhost:80` would +still have a source IP of 127.0.0.1 when received by the container, so no +packets would respond. Again, it is a sequence of 3 chains. Because SNAT has to +occur in the `POSTROUTING` chain, the packet has already been through the DNAT +chain. + +`POSTROUTING`: +- `-s 127.0.0.1 ! -d 127.0.0.1 -j CNI-HOSTPORT-SNAT` + +`CNI-HOSTPORT-SNAT`: +- `-j CNI-SN-xxxxx` + +`CNI-SN-xxxxx`: +- `-p tcp -s 127.0.0.1 -d 172.16.30.2 --dport 80 -j MASQUERADE` We definitely don't need the -s. I added the -d and --dport so that the minimal possible set of traffic from 127.0.0.1 is allowed out. Otherwise this is a nasty potential firewall bypass owing to the fact that route_localnet is enabled. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVIilQemzhSD98T156FMJuO0wF4flks5rmCZFgaJpZM4MbqAA> .

squeed · 2017-03-17T22:26:46Z

I'm not 100% certain about the firewall bypass, but my though is that, since we've enabled route_localnet, if all traffic from 127.0.0.1 to the 'net gets MASQ'd, this happens after the OUTPUT chain on the filter table. Any policies that depend on source ip or if could be skipped.
Yeah, it's a bit contrived, but not too weird, as far as these things go.

In any case, I'll be on vacation, offline for the coming week. This PR is editable by the general team - all are free to make changes.

squeed · 2017-04-12T13:00:06Z

Yeah, I was partially right about the firewall bypass - it's slightly contrived, but IMHO worth preventing. If you have a FILTER rule that specifies the source IP, then it is bypassed.

e.g.

iptables -t filter -A OUTPUT -p tcp -s 192.168.121.184 --dport 5050 -j DROP

Then if you have

iptables -t nat -A POSTROUTING -s 127.0.0.1 ! -d 127.0.0.1 -j MASQUERADE

This command works, though it shouldn't:

nc -s 127.0.0.1 10.7.18.117 5050

Admittedly it's a bit silly to have source IPs in the filter.OUTPUT chain, but it's plausible. Given that we also intend to use this plugin in rkt, which is a bit more general-purpose than k8s, I'm going to keep the more specific MASQUERADE entry conditions.

dcbw · 2017-04-21T17:19:42Z

plugins/portmap/README.md

+ },
+ {
+ "type": "portmap",
+ "capabilities": {"portMappings": true}


feiskyer · 2017-05-02T11:24:33Z

Any updates on this?

squeed · 2017-05-02T15:56:24Z

Sorry, this fell off of my plate. I should be done with this in the next few days.

caseydavenport · 2017-05-02T18:16:18Z

We open and bind() the actual port on the host.

It does sound like a helper daemon might be desired for this, and the dst type LOCAL concerns as well.

This feels like a minor enough window to me that I'd be happy to pass on it for now and add later if it becomes a problem, or once we add a helper daemon for some other reason.

caseydavenport · 2017-05-02T17:13:46Z

plugins/portmap/README.md

+You should use this plugin as part of a network configuration list. It accepts
+the following configuration options:
+
+* `noSnat` - boolean, defaul false. If true, do not set up the SNAT chains


typo: defaul

caseydavenport · 2017-05-02T17:32:55Z

plugins/portmap/README.md

+8080 and 8043 on the host forwarded to ports 80 and 443 in the container, the 
+rules look like this:
+
+`PREROUTING`, `OUTPUT` chains:


In the interest of progressing this PR, why don't we start by implementing this the way it's written today (any addresses in the local routing table) and then follow up with a fix using ipsets?

It wouldn't be a regression in behavior since that's how k8s behaves today, and so long as we have a plan for how to fix in a second release then I think I'm OK with it.

An alternative would be to document this as "must be the last rule in the chain" but that feels very brittle in the face of collaboration users of iptables

Yeah it does, but maybe it's fine as a first step?

thockin · 2017-05-02T18:28:19Z

And to be fair, I sort of hate the "specific IPs" model, too - still hoping for a better answer.

…

On Tue, May 2, 2017 at 11:17 AM, Casey Davenport ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In plugins/portmap/README.md <#1 (comment)> : > @@ -0,0 +1,103 @@ +## Port-mapping plugin + +This plugin will forward traffic from one or more ports on the host to the +container. It expects to be run as a chained plugin. + +## Usage +You should use this plugin as part of a network configuration list. It accepts +the following configuration options: + +* `noSnat` - boolean, defaul false. If true, do not set up the SNAT chains typo: defaul ------------------------------ In plugins/portmap/README.md <#1 (comment)> : > +## Rule structure +The plugin sets up two sequences of chains and rules - one "primary" DNAT +sequence to rewrite the destination, and one additional SNAT sequence that +rewrites the source address for packets from localhost. The sequence is somewhat +complex to minimize the number of rules non-forwarded packets must traverse. + + +### DNAT +The DNAT rule rewrites the destination port and address of new connections. +There is a top-level chain, `CNI-HOSTPORT-DNAT` which is always created and +never deleted. Each plugin execution creates an additional chain for ease +of cleanup. So, if a single container exists on IP 172.16.30.2 with ports +8080 and 8043 on the host forwarded to ports 80 and 443 in the container, the +rules look like this: + +`PREROUTING`, `OUTPUT` chains: In the interest of progressing this PR, why don't we start by implementing this the way it's written today (any addresses in the local routing table) and then follow up with a fix using ipsets? It wouldn't be a regression in behavior since that's how k8s behaves today, and so long as we have a plan for how to fix in a second release then I think I'm OK with it. An alternative would be to document this as "must be the last rule in the chain" but that feels very brittle in the face of collaboration users of iptables Yeah it does, but maybe it's fine as a first step? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVBQukRnyflKQjNpQBJVPpXJyqULVks5r13MwgaJpZM4MbqAA> .

squeed · 2017-05-03T14:37:39Z

Ok, I pushed an update to the plugin. It now takes a conditions argument (actually, one per family) so that the administrator can arbitrarily add conditions to the forwarding entry rules. While this doesn't directly solve the GKE / LOCAL problem, it does mean that fixing it is not a code change.

At this point in time, I feel it's ready for a release. Adding a port-reservation daemon would be a welcome addition, but that can be an additional feature.

thockin · 2017-05-05T06:38:16Z

I'm not sure I see how the conditions fixes the local problem, but I am OK to get this in and iterate..

feiskyer · 2017-05-05T07:09:37Z

+1 for get this in first.

squeed · 2017-05-05T09:57:50Z

The idea is so the admin can add additional conditions to patch up the local problem. One could exclude or require specific subnets, if those are predictable and distinct, for example.

…

On Fri, May 5, 2017 at 8:38 AM, Tim Hockin ***@***.***> wrote: I'm not sure I see how the conditions fixes the local problem, but I am OK to get this in and iterate.. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAhp0ghnrAdrht_nU07dwEZeXi5Zh7uvks5r2sPYgaJpZM4MbqAA> .

thockin · 2017-05-05T15:28:57Z

excluding subnets isn't going to help the problem I see. besides that, a single "conditions" block doesn't allow me to exclude 2 different ranges. To solve the problem I see (or rather, the way I know how - please teach me if I am wrong :) is to change 1 "addrtype LOCAL" rule into N "-d" rules. On Fri, May 5, 2017 at 2:57 AM, Casey Callendrello <[email protected]

…

wrote: The idea is so the admin can add additional conditions to patch up the local problem. One could exclude or require specific subnets, if those are predictable and distinct, for example. On Fri, May 5, 2017 at 8:38 AM, Tim Hockin ***@***.***> wrote: > I'm not sure I see how the conditions fixes the local problem, but I am OK > to get this in and iterate.. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/containernetworking/plugins/ pull/1#issuecomment-299393536>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAhp0ghnrAdrht_ nU07dwEZeXi5Zh7uvks5r2sPYgaJpZM4MbqAA> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVKpqdng9ahFoyEgimoxk71ZXVvMHks5r2vKggaJpZM4MbqAA> .

squeed · 2017-05-05T17:08:43Z

I'm sure both of us don't quite have the whole picture :-).

With a single iptables rule you can exclude multiple ranges. You just can't include multiple ranges directly. In other words, iptables matches are always AND, never OR. However, you can match on multiple ranges using ipsets, which adds a bit more complexity but isn't too bad.

In any case, any administrator-provided conditions would be in addition to the --addrtype LOCAL.

Could you provide a more concrete example of how the GCE vips appear on the host? It's a bit tricky to reason about otherwise. I was assuming the machine had an eth0 of, say, 10.42.1.2 and an additional local routing table entry of, say, 8.8.8.8.

Does it make sense? My goal is to produce something simple and broadly useful, and this is a very good motivating example. I'm happy to try and get it right.

thockin · 2017-05-05T18:27:38Z

How do you exclude multiple ranges? ``` # iptables -t nat -d 1.2.3.0/24 ! -d 1.2.3.0/25 -j LOG iptables v1.4.21: multiple -d flags not allowed Try `iptables -h' or 'iptables --help' for more information. ``` When a packet to a VIP arrives at the node, srcip is the original client, and dstip is the LB VIP. To make the kernel receive it in normal VM-mode, the LB IP is added to the `local` route table. Because we mux containers to nodes N:1, we demux LB packets in iptables. We recognize the dstip and dstport, and DNAT based on that. The problem is that those packets match addrtype LOCAL *and* the VIP-specific rule. So we could demand ordering, and say that hostport checks should always be at the end. That seems delicate. We could just code the list of allowed IPs for hostports. That's tedious, but seems semantically closer. Very open to better ideas.

…

On Fri, May 5, 2017 at 10:08 AM, Casey Callendrello < ***@***.***> wrote: I'm sure both of us don't quite have the whole picture :-). With a single iptables rule you can *exclude* multiple ranges. You just can't *include* multiple ranges directly. In other words, iptables matches are always AND, never OR. However, you can match on multiple ranges using ipsets, which adds a bit more complexity but isn't too bad. In any case, any administrator-provided conditions would be in addition to the --addrtype LOCAL. Could you provide a more concrete example of how the GCE vips appear on the host? It's a bit tricky to reason about otherwise. I was assuming the machine had an eth0 of, say, 10.42.1.2 and an additional local routing table entry of, say, 8.8.8.8. Does it make sense? My goal is to produce something simple and broadly useful, and this is a very good motivating example. I'm happy to try and get it right. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVNA2W24rkSNNnDzrQ5fXMmqB9P9zks5r21ecgaJpZM4MbqAA> .

squeed · 2017-05-05T19:53:27Z

Argh, you're totally right about multiple -d. I don't know what the heck I was thinking.

gunjan5 · 2017-05-08T23:53:51Z

plugins/portmap/main.go

+}
+
+func main() {
+ skel.PluginMain(cmdAdd, cmdDel, version.PluginSupports("", "0.1.0", "0.2.0", version.Current()))


Any reason why the supported versions are specified this way? This will skip 0.3.0 since version.Current() returns 0.3.1, and your sample config in the README.md uses 0.3.0 https://github.com/containernetworking/plugins/pull/1/files#diff-f6ee9b32ca4cfb6c2075e1ee55dadd07R22

CNI_COMMAND=VERSION ./portmap < conf {"cniVersion":"0.3.1","supportedVersions":["","0.1.0","0.2.0","0.3.1"]}

I see other CNI plugins just use version.All .

gunjan5 · 2017-05-26T16:14:03Z

plugins/meta/portmap/README.md

+The plugin expects to receive the actual list of port mappings via the 
+`portMappings` [capability argument](https://github.com/containernetworking/cni/blob/master/CONVENTIONS.md)
+
+So a sample config might look like:


what do you think about adding a note or a line here mentioning that the config should have a .conflist extension?

squeed · 2017-05-29T21:26:52Z

@caseydavenport added some ip(6)tables error-ignoring logic, PTAL.

caseydavenport

@squeed new ipv6 logic seems sound to me. I'll try it out when I'm in the office tomorrow.

caseydavenport · 2017-05-29T22:04:02Z

plugins/meta/portmap/portmap.go

+ ip4t := maybeGetIptables(false)
+ ip6t := maybeGetIptables(true)
+ if ip4t == nil && ip6t == nil {
+ return fmt.Errorf("neither iptables not ip6tables usable")


caseydavenport · 2017-05-31T01:54:41Z

plugins/meta/portmap/portmap.go

+ return nil
+ }
+
+ _, err = ipt.List("filter", "OUTPUT")


So it turns out this check isn't great because it checks the filter table, whereas the portmap plugin uses the nat table, and it's possible to have the one but not the other :D

# ip6tables -L -t nat ip6tables v1.6.0: can't initialize ip6tables table `nat': Table does not exist (do you need to insmod?) Perhaps ip6tables or your kernel needs to be upgraded # ip6tables -L -t filter Chain INPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere ACCEPT tcp anywhere anywhere tcp dpt:22 Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere

Awesome. Looks like v6 nat support was added in kernel 3.7.

Fixed.

bboreham · 2017-05-31T16:56:28Z

Should we consider adding iptables ACCEPT rules for the case where the machine has default deny? kubernetes/kubernetes#35069

squeed · 2017-05-31T17:03:59Z

one last TODO: need to make the teardown code not use indexes, or else we risk stepping on our own toes.

squeed · 2017-05-31T17:22:09Z

And, updated - delete now deletes by rule directly.

caseydavenport · 2017-05-31T22:29:05Z

@squeed LGTM!

bboreham · 2017-06-01T12:05:24Z

LGTM

Support delegating to Windows CNI - use a separate WindowsDelegate field as the format of Windows properties is different from the schema supported by Linux under the delegate field. This will users to configure both Linux and Windows together and also to use Windows specific configuration for Windows clusters.

update integration test configlist

Noop - A noop PR

squeed mentioned this pull request Mar 13, 2017

iptables-based default portmap plugin containernetworking/cni#378

Closed

This was referenced Mar 14, 2017

Evaluate port mapping containernetworking/cni#46

Closed

Move HostPort port-opening from kubenet to kubelet/cni kubernetes/kubernetes#31307

Closed

thockin reviewed Mar 14, 2017

View reviewed changes

Bregor mentioned this pull request Mar 31, 2017

HostPort seemingly not working kubernetes/kubernetes#23920

Closed

dcbw mentioned this pull request Apr 21, 2017

Update CNI plugin to newest version; support ConfigLists kubernetes/kubernetes#42202

Merged

dcbw reviewed Apr 21, 2017

View reviewed changes

plugins/portmap/README.md Outdated

},

{

"type": "portmap",

"capabilities": {"portMappings": true}

Copy link

Member

dcbw Apr 21, 2017

Choose a reason for hiding this comment

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

Indent?

This was referenced Apr 24, 2017

Support port mapping kubernetes-retired/frakti#122

Closed

cnitool: support capablity args containernetworking/cni#440

Merged

caseydavenport reviewed May 2, 2017

View reviewed changes

squeed force-pushed the portmap-plugin branch from 32c527d to 705dc4e Compare May 3, 2017 14:35

gunjan5 reviewed May 8, 2017

View reviewed changes

gunjan5 reviewed May 26, 2017

View reviewed changes

squeed force-pushed the portmap-plugin branch from 0e7a45d to 64f6e3e Compare May 29, 2017 21:26

caseydavenport reviewed May 29, 2017

View reviewed changes

squeed force-pushed the portmap-plugin branch 2 times, most recently from b7d3c0e to 9afd469 Compare May 30, 2017 13:09

caseydavenport mentioned this pull request May 31, 2017

Add portmap plugin projectcalico/cni-plugin#338

Merged

2 tasks

caseydavenport reviewed May 31, 2017

View reviewed changes

squeed force-pushed the portmap-plugin branch from 9afd469 to e4b00ab Compare May 31, 2017 10:12

Casey Callendrello added 2 commits May 31, 2017 18:32

vendor: update coreos/go-iptables

539174f

vendor: add libcni

b47d5b7

squeed force-pushed the portmap-plugin branch from e4b00ab to 3252d89 Compare May 31, 2017 16:48

squeed force-pushed the portmap-plugin branch from 3252d89 to 8c2e820 Compare May 31, 2017 17:03

vendor: add mattn/go-shellwords

22cda76

squeed force-pushed the portmap-plugin branch from 8c2e820 to 0060ed9 Compare May 31, 2017 17:21

squeed force-pushed the portmap-plugin branch from 0060ed9 to f6550f8 Compare May 31, 2017 17:23

plugins/meta/portmap: add an iptables-based host port mapping plugin

a7aaf0e

squeed force-pushed the portmap-plugin branch from f6550f8 to a7aaf0e Compare June 1, 2017 08:06

bboreham merged commit 0997c53 into containernetworking:master Jun 1, 2017

Lion-Wei pushed a commit to Lion-Wei/plugins that referenced this pull request Apr 10, 2018

Merge pull request containernetworking#1 from Lion-Wei/runtime-config

9212565

update integration test configlist

dcbw mentioned this pull request Oct 16, 2019

static: prioritize the input sources for IPs #400

Merged

lsm5 pushed a commit to lsm5/containernetworking-plugins that referenced this pull request Oct 24, 2019

Merge pull request containernetworking#1 from openshift/noop

798823b

Noop - A noop PR

B-Betty mentioned this pull request Sep 8, 2021

portmap plugin lead to iptables lock #662

Closed

destanyinside mentioned this pull request Aug 29, 2022

cni plugin dhcp does't lease renewing after restart #767

Closed

iptables-based portmapping plugin #1

iptables-based portmapping plugin #1

Conversation

squeed commented Mar 13, 2017

thockin 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

squeed commented Mar 15, 2017

thockin commented Mar 15, 2017 via email

thockin commented Mar 17, 2017 via email

thockin commented Mar 17, 2017 via email

squeed commented Mar 17, 2017

squeed commented Apr 12, 2017

Choose a reason for hiding this comment

feiskyer commented May 2, 2017

squeed commented May 2, 2017

caseydavenport commented May 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thockin commented May 2, 2017 via email

squeed commented May 3, 2017

thockin commented May 5, 2017

feiskyer commented May 5, 2017

squeed commented May 5, 2017 via email

thockin commented May 5, 2017 via email

squeed commented May 5, 2017

thockin commented May 5, 2017 via email

squeed commented May 5, 2017

gunjan5 May 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

squeed commented May 29, 2017

caseydavenport 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

bboreham commented May 31, 2017

squeed commented May 31, 2017

squeed commented May 31, 2017

caseydavenport commented May 31, 2017

bboreham commented Jun 1, 2017

gunjan5 May 8, 2017 •

edited

Loading