feat(*) adding kumactl install transparent-proxy

[nickolaev]

Summary

Expanding kumactl with new commands to manage host setting and enable Transparent Proxy mode:

kumactl install transparent-proxy --kuma-dp-user kuma-dp --kuma-cp-ip 1.2.3.4

The kuma-dp user should be pre-created on the host and the kuma-dp process should be started as this user. One option is to use runuser

The typical Dataplane resource to be used with transparent proxy looks like this:

type: Dataplane
mesh: default
name: {{ name }}
networking:
  address: {{ address }}
  inbound:
  - port: {{ port }}
    tags:
      kuma.io/service: demo-client
  transparentProxying:
    redirectPortInbound: 15006
    redirectPortOutbound: 15001

Where {{ name }}, {{ address }} and {{ port }} can be command line substituted variables. The ports 15001 and 15006 are the defaults set in kumactl install transparent-proxy. The additional flags --redirect-inbound-port and --redirect-outbound-port will set these to whatever values are needed.

A full command that runs kuma-dp process as kuma-dp user and substitutes the variables in the yaml:

runuser -u kuma-dp -- /usr/bin/kuma-dp run --cp-address=https://172.19.0.2:5678 --dataplane-token-file=/kuma/token-demo --dataplane-file=/kuma/dpyaml-demo --dataplane-var name=dp-demo --dataplane-var address=172.19.0.4 --dataplane-var port=80  --binary-path /usr/local/bin/envoy

Reverting the transparent proxy changes made on the host:

kumactl uninstall transparent-proxy

Documentation

• Link to the website documentation PR

[subnetmarco]

Even if the user installs transparent proxying in some hosts, they may still be setting up outbound sections in their data plane proxy specifications.

• Do we need to show a warning when that happens?
• Do we keep it working?
• Will it work in conjunction with transparent proxying?

[nickolaev]

• Do we need to show a warning when that happens?

We do have an explicit check for this already:

		// this part of validation works only for Universal scenarios with TransparentProxying
		if dp.Spec.Networking.TransparentProxying != nil && len(dp.Spec.Networking.Outbound) != 0 {
			var err validators.ValidationError
			err.AddViolation("outbound", "should be empty since dataplane is in Transparent Proxying mode")
			return nil, err.OrNil()
		}

This happens late in the generation process, so this message is seen on the envoy console, it may make sense to actually check this early when the Dataplane is instantiated.

• Do we keep it working?

The iptables rules we deploy have an explicit rule that does not redirect any traffic that is towards localhost. This essentially prevent us from having localhost:4000 listeners. Well we can have these, but they will never get any traffic when the iptables rules are deployed.

• Will it work in conjunction with transparent proxying?

It technically can be made to work with some patching, but then we have the iptables rules not forwarding the traffic. Not saying it is impossible, it just will make things harder to maintain in production, and I personally don't see any particular benefit.

[jakubdyszkiewicz]

Some nits here and there but overall nice 👏

[jakubdyszkiewicz]

else: print something like iptables modified.

What happens if I run this command twice?

[jakubdyszkiewicz]

can you maybe extract this to method modifyIptables()? and below to modifyResolvConf()?

[nickolaev]

Resolv.conf will not be modified for sure. I think iptables will not too.

[jakubdyszkiewicz]

the ... end? :D
btw. is it IP only without port? can this be a hostname?

[jakubdyszkiewicz]

I think instead of printing resolv.conf I'd print something like:

/etc/resolv.conf modified. The previous version of the file backed up to /etc/resolv.conf.kuma

nit: how about instead of /etc/resolv.conf.kuma call it /etc/resolv.conf.kuma-backup or /etc/resolv.conf.backup-by-kuma. Also it would be nice to add as a first line a comment to this file:

# This file was backed up by kumactl install transparent proxy

[nickolaev]

All applied except for modifying the file, as it will make restoring it slightly harder. But meanwhile, its name is still saying enough (kuma-backup).

[jakubdyszkiewicz]

nit: just DefaultTransparentProxy() without Get, to follow our convention in components.go files.

[jakubdyszkiewicz]

why do we need iterations?

[nickolaev]

well, just to have more tries and see it is consistent.

[jakubdyszkiewicz]

but we do have DoWithRetry in the iterations. Even if this is not consistent (example - every other request works), it will be retried in the loop and the test will pass.

[jakubdyszkiewicz]

instead of messing around with global os.Args and os.Stdout, can we do it like with tests?

cmd := install.GetCommand()

cmd.SetArgs(...)

stdout := &bytes.Buffer{}
stderr := &bytes.Buffer{}
cmd.SetOut(stdout)
cmd.SetErr(stderr)

err := cmd.Execute()

stdout.Bytes()

[nickolaev]

Unfortunately no, because:

• viper validates that everything in os.Args is a valid flag, and it does not expect to find there our own flags
• the execute functions in istio-iptabes are directly writing to os.Stdout, there is no way around this

[jakubdyszkiewicz]

but we do have DoWithRetry in the iterations. Even if this is not consistent (example - every other request works), it will be retried in the loop and the test will pass.