Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tailscale Kubernetes Operator

tailscale.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Tailscale Kubernetes Operator

#51

Post by shawabawa3 »

ratg13 wrote: post #46
HappyCathode wrote: post #19

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.

Machines can have unlimited expiry

API keys have 90 day expiry but you can get around that with an oauth app that has credentials that don't expire

Re: Tailscale Kubernetes Operator

#52

Post by peterbecich »

radlad wrote: post #42
sneak wrote: 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?

I'm a big fan of Nix Flakes but they appear to have the same issue here as "curl | bash".

I mention this because Flakes can do much of what Docker can do, but do not use containers or virtualization.

The official NixPkgs are carefully vetted. Nix Flakes make it more convenient to pull in sources from outside NixPkgs.

As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. There are more benefits to Nix Flakes than native execution so containerizing them somehow might be an acceptable compromise.

Re: Tailscale Kubernetes Operator

#53

Post by one-punch »

peterbecich wrote: post #52
radlad wrote: 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?

I'm a big fan of Nix Flakes but they appear to have the same issue here as "curl | bash". I mention this because Flakes can do much of what Docker can do, but do not use containers or virtualization. The official NixPkgs are carefully vetted. Nix Flakes make it more convenient to pull in sources from outside NixPkgs. As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. There a…

> As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them.

You may be interested in nix snapshotter, which can run nix packages in containerd.

https://news.ycombinator.com/item?id=37407758

Re: Tailscale Kubernetes Operator

#54

Post by ratg13 »

neurostimulant wrote: post #50
ratg13 wrote: post #46

Earlier quoted context omitted.

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.

Thank you, I will take a look for this and give it a try.

Re: Tailscale Kubernetes Operator

#55

Post by jabradoodle »

pkage wrote: post #41
sneak wrote: post #40

Earlier quoted context omitted.

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)

It doesn't, it removes/reduces one step, and leaves another one that is there regardless.

Re: Tailscale Kubernetes Operator

#56

Post by TeMPOraL »

radlad wrote: post #49
pphysch wrote: post #47

Earlier quoted context omitted.

There have been a lot of container escape exploits

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

That depends on how you're running it. You wouldn't want a compromised image to be the base for your build containers, which get access to your product's source code via volume mount, or to secret keys via environment variables.
Post reply on HN