Live data from Hacker News

Tailscale Kubernetes Operator

tailscale.com

41–50 of 56 posts

Re: Tailscale Kubernetes Operator

#41
post #40

Earlier quoted context omitted.

You could say this about any service serving software artifacts?

Unsigned ones, yes.

That just moves the trust requirement up the chain, and assumes that the image wasn’t compromised pre-signing (either intentionally or unintentionally)

Re: Tailscale Kubernetes Operator

#42
post #12

The amount of trust placed in DockerHub to serve the correct images to everyone for uncritical download and execution is insane to me. The whole industry does it, and it's the same as "curl | bash" to specify image:tag and not image@hash. If I were TAO I'd apply for a job at Docker or their hosting provider.

> it's the same as "curl | bash"

While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container.

Even if you specify a hash, are you actually checking all of the code and binaries in that image?

What about the image base (e.g. Alpine, Debian) and their packages?

Re: Tailscale Kubernetes Operator

#43
post #12

The amount of trust placed in DockerHub to serve the correct images to everyone for uncritical download and execution is insane to me. The whole industry does it, and it's the same as "curl | bash" to specify image:tag and not image@hash. If I were TAO I'd apply for a job at Docker or their hosting provider.

What's the alternative? I don't know of any reason to think that tarballs or installers are any better. I suppose I could clone the code and look for security flaws myself but I'm no expert and on something like nginx it's certain to be a waste of my time.

OCI registries.

Harbor + Notary + admission controllers - AKA private image repository with image signing.

Sigstore. Another method for signing & verifying artifacts.

Re: Tailscale Kubernetes Operator

#45
post #12

The amount of trust placed in DockerHub to serve the correct images to everyone for uncritical download and execution is insane to me. The whole industry does it, and it's the same as "curl | bash" to specify image:tag and not image@hash. If I were TAO I'd apply for a job at Docker or their hosting provider.

[dead]

Re: Tailscale Kubernetes Operator

#46

Earlier quoted context omitted.

You can use Cloudflare access for internal which is tunnel + identity access management for end users.

I'de rather have full network isolation for internal stuff like admin portals. Plus, I already use Tailscale to sync DBs between regions and clouds.

My only issue with Tailscale was that it can't seem to stay logged in longer than something like 45 or 90 days.. making it a fun toy, but not for enterprise use.

As someone who travels a lot with machines all over the world, if a node goes offline I can ask someone to reboot a machine .. but there is no way I am giving random people credentials to my machines and network to fix issues.

Re: Tailscale Kubernetes Operator

#47
post #42
post #12

The amount of trust placed in DockerHub to serve the correct images to everyone for uncritical download and execution is insane to me. The whole industry does it, and it's the same as "curl | bash" to specify image:tag and not image@hash. If I were TAO I'd apply for a job at Docker or their hosting provider.

> it's the same as "curl | bash" While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container. Even if you specify a hash, are you actually checking all of the code and binaries in that image? What about the image base (e.g. Alpine, Debian) and their packages?

There have been a lot of container escape exploits

Re: Tailscale Kubernetes Operator

#48
I think an alternative solution would be nice, where services are just registered with their service discovery, though I suppose that would require them providing an official API for that part of their product.

In my current setup for Tailscale + Kubernetes, I just use their subnet router[0] and add the kubedns server for the cluster.local domains to their MagicDNS. Having proper service discovery would make this into a nice round solutionl.

[0]: https://tailscale.com/kb/1185/kubernetes/#subnet-router

Re: Tailscale Kubernetes Operator

#49
post #47
post #42

Earlier quoted context omitted.

> it's the same as "curl | bash" While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container. Even if you specify a hash, are you actually checking all of the code and binaries in that image? What about the image base (e.g. Alpine, Debian) and their packages?

There have been a lot of container escape exploits

Sure... but it's still not "the same as" running on your host.

Re: Tailscale Kubernetes Operator

#50
post #46

Earlier quoted context omitted.

I'de rather have full network isolation for internal stuff like admin portals. Plus, I already use Tailscale to sync DBs between regions and clouds.

My only issue with Tailscale was that it can't seem to stay logged in longer than something like 45 or 90 days.. making it a fun toy, but not for enterprise use. As someone who travels a lot with machines all over the world, if a node goes offline I can ask someone to reboot a machine .. but there is no way I am giving random people credentials to my machines and network to fix issues.

There is an option to disable key expiry in the machine settings, unless you're talking about a different issue / bug. In my case, simply turning off key expiry is enough to keep the machine online for months inside tailscale network so far.
Post reply on HN