[HN Gopher] Tailscale Kubernetes Operator
___________________________________________________________________
Tailscale Kubernetes Operator
Author : l2dy
Score : 142 points
Date : 2023-09-22 12:39 UTC (10 hours ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| drewda wrote:
| We've been using https://github.com/mvisonneau/docker-tailscale/
| on k8s clusters. Good to see an official option coming.
| Axsuul wrote:
| Same however I'm using HashiCorp Nomad so hope for an official
| option there.
| hobofan wrote:
| 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
| sneak wrote:
| 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.
| samcat116 wrote:
| You could say this about any service serving software
| artifacts?
| sneak wrote:
| Unsigned ones, yes.
| pkage wrote:
| That just moves the trust requirement up the chain, and
| assumes that the image wasn't compromised pre-signing
| (either intentionally or unintentionally)
| Proven wrote:
| [dead]
| api wrote:
| We have collectively decided as an industry to place infinite
| trust in a handful of vendors for the sake of convenience.
|
| Auth providers (OIDC), cloud providers, and numerous software
| repositories and SaaS providers effectively have root on the
| entire universe. A major compromise of any number of these
| large vendors could expose millions of systems to total
| compromise.
| [deleted]
| sneak wrote:
| Resultantly, these systems are almost certainly already
| compromised by organizations skilled enough to not get
| caught.
| api wrote:
| I'd say nation states, which means the US and possibly
| other nation states effectively have root on virtually all
| SaaS systems.
|
| It's exactly the architecture I'd promote if I wanted a
| total panopticon, but I'm not suggesting a conspiracy. Ease
| of use is the most powerful force in computing and history
| has shown that people will trade privacy, security,
| freedom, cost, and virtually anything else for it.
|
| It does make a certain amount of sense. Time is non-
| fungible; no amount of money can buy more of it. So ease of
| use by saving time is extremely valuable and commands a
| high price.
|
| The problem is that IMO the cost of all this SaaS
| automation is higher than most people understand. There's
| some rather huge hidden costs here.
| anonfunction wrote:
| What's TAO?
| Infernal wrote:
| I am not sure but maybe referring to this?
| https://en.wikipedia.org/wiki/Tailored_Access_Operations
| zalanak wrote:
| Might be referring to "Tailored Access Operations" which was
| an NSA office
| nineplay wrote:
| What's the alternative? I don't know of any reason to think
| that tarballs or <os> 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.
| eatmyshorts wrote:
| OCI registries.
|
| Harbor + Notary + admission controllers - AKA private image
| repository with image signing.
|
| Sigstore. Another method for signing & verifying artifacts.
| Lemmi wrote:
| That's why you only pull official images and signed ones.
|
| And that's why I have an in-between step.
|
| Harbor.io allows you to configure it as a proxy with approval
| mechanism and cve scanning
| sneak wrote:
| Docker content trust (ie signature checking) is disabled by
| default.
|
| We won't even do this for webpages, but we find it a fine
| default for code that executes inside critical
| infrastructure.
|
| It's utter madness. Cool to see someone is doing something
| about it.
| johnmaguire wrote:
| > 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?
| pphysch wrote:
| There have been a lot of container escape exploits
| johnmaguire wrote:
| Sure... but it's still not "the same as" running on your
| host.
| knodi wrote:
| Love it!!! This is going to make (my) dev and testing env cluster
| so much easier.
|
| Now imagine running derp-server with in the DC with your k8s.
| HappyCathode wrote:
| That's really neat. Cloudflare tunnel for external customer
| egress, and Tailscale for internal tool egress. No more costly
| cloud specific load balancers !
| BasedInfra wrote:
| You can use Cloudflare access for internal which is tunnel +
| identity access management for end users.
| HappyCathode wrote:
| 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.
| ratg13 wrote:
| 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.
| shawabawa3 wrote:
| 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
| neurostimulant wrote:
| 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.
| maisem wrote:
| Hi Tailscale engineer here. The operator also supports
| Tailscale Funnel so you could use that instead of Cloudflare
| tunnel if you desired.
| HappyCathode wrote:
| Hey ! I see Tailscale Funnels as maybe a good replacement for
| Ngrok, but not for Cloudflare Tunnels.
|
| Your Funnels are in Beta, MUST use your tailnet's domain
| name, have bandwitdh limits, no failover and no load
| balancing. If my website goes down, I close shop. Cloudflare
| Tunnels are just way more mature for production loads. CF
| Tunnels technically don't have load balancing, but if you set
| multiple Tunnels with the same ID, you get some sort of load
| balancing AND failovers if a tunnel goes down. And after
| that, they have a paid Load Balancer option.
|
| Even for internal admin portals, the mention that "Traffic
| over Funnel is subject to bandwidth limits." with absolutely
| no defined numbers is just a turn off. If you added a number
| to that, like a limit of MBPS or GB/Month of transfer, it
| would be something I can bring to my colleagues, something we
| can discuss and weight on. For now, with no number, it's just
| a threat.
|
| Everything else about Tailscale is _chefskiss_ tho ;)
| thelastparadise wrote:
| It's a neat idea but I wouldn't put this in my k8s cluster.
|
| Keep it simple st*pid!
| berkle4455 wrote:
| k8s cluster and simple are rarely found together.
| leetrout wrote:
| You can use, instead:
|
| Keep it simple, smarty
| [deleted]
| ses1984 wrote:
| Keep it super simple.
| SanderNL wrote:
| [flagged]
| birdyrooster wrote:
| [flagged]
| valvar wrote:
| Is "stupid" really one of the words that the Ministry of
| Truth no longer permits us to use?
| wenebego wrote:
| 1984 is when people dont like being called stupid
| biohax2015 wrote:
| It's just rude
| leetrout wrote:
| They felt the need to censor it as st*pid so I merely
| offered the alternative I use.
| gmemstr wrote:
| Maybe not wise to post here _yet_ as the docs mark this as a
| private alpha.
| yebyen wrote:
| Maybe so, as what we're doing in absence of proper docs is
| rightly classified as something worse than alpha. The best docs
| they had so far up to this point:
|
| https://tailscale.com/kb/1185/kubernetes/
|
| These are great, for someone who knows Kubernetes. You should
| understand that creating the tailscale subnet router as a pod
| directly means the connection is not resilient. It's also key
| to understand that tailscale will break if you have more than
| one instance of subnet router at a time, so substituting
| Deployment in place of where these docs use Pod is not a really
| good choice without some fine tuning because of the risk that a
| rolling update creates another copy of the pod before the old
| one has shut down.
|
| Maybe stateful set, if there was a way to permanently imply
| that statefulset can only have one replica. I appreciate the
| link anyway. I figured all this out on my own, and I'm using
| tailscale productively with Kubernetes based on the old docs,
| with my open source project. Tailscale has a great and generous
| free software tier for supporting OSS maintainers. :tada:
| tecleandor wrote:
| Nice! I think I'll try to implement this in my TrueNAS this
| weekend, as it makes way way easier to access all the services I
| deploy there.
|
| TrueCharts charts have Tailscale support, but not all my charts
| are from there, and also I'm kind of avoiding them.
|
| Also, it's nice if you deploy something without a chart.
| Stem0037 wrote:
| Does it support headscale? https://github.com/juanfont/headscale
| shawabawa3 wrote:
| One thing that i think is really missing is redundancy on the
| proxies
|
| Currently there's no way to have two proxies that listen on the
| same tailscale hostname/ip
|
| Ideally in Kubernetes every pod is redundant to allow downscaling
| of nodes efficiently, so this means we have to eat a minute or so
| of downtime randomly every now and then on our tailscale
| endpoints
| gameoverhumans wrote:
| I agree, it's a feature that I find sorely lacking in my
| tailnet.
|
| These are the relevant Github issues to follow, hopefully they
| address these someday:
|
| https://github.com/tailscale/tailscale/issues/465
| https://github.com/tailscale/tailscale/issues/4324
| vorpalhex wrote:
| Can't you expose the services to two load balancers?
|
| Not ideal for anything customer facing but fine enough for
| staff.
| shawabawa3 wrote:
| they would have to have two separate hostnames/ips so you
| wouldn't have a single redundant endpoint
___________________________________________________________________
(page generated 2023-09-22 23:01 UTC)