darren0

From the description

"Please note that content shared with this addon is just cached on IPFS servers. If you want to store the content permanently, you need to have IPFS node running on your computer."

It's a common misconception that ipfs is something you can "upload to." Ipfs makes links permanent in that they will never change. There is no guarantee that the content of the link exists unless someone explicitly stored it on a node.

Somewhat related, rootless docker and kubernetes https://github.com/rootless-containers/usernetes

(Disclaimer: I'm from Rancher Labs)

Unfortunately, none of the tech referenced in this articled is available yet and should be released end of February. There is a more interesting part that isn't referenced in this article and the is that we'll have two variants of k8s for ARM. One is RKE which is our CNCF certified k8s distribution. The other will be based off k3s (github.com/ibuildthecloud/k3s) which is an optimized k8s distribution for small clusters (smaller memory, easier setup, etc). I expected the second will be far more suited for something like this project.

I'm fairly confident this issue has existed since pretty much the beginning of k8s. It is possible it doesn't go back that far because SPDY used to be used and not websockets. The basic Upgrade logic still applies so I assume it was there. This flaw is actually in quite a few open source projects, it's a common approach and mistake. For most projects it results in a functional bug, not a security issue.

I personally found this issue and highly doubt anybody previously exploited it. This bug was discovered from the perspective of a functional bug and only later realized it had a security impact. So it wasn't like somebody was first hacked, and also a security researcher didn't find it either. Basically this issue is very nuanced and I don't think many would be looking for it (although people will now).

Although plenty of people are saying the sky is failing, this is mostly a privileged escalation issue which means you first need valid access to do something harmful. So it's not a fabulous attack vector because hard multitenant clusters are extremely rare. Searching for anonymous auth on kubelets is a better use of your time.

The PoC is mostly correct, but basically is testing for a side effect of the fix, not the presence of the vulnerability. Either which way it's probably still useful, but since we are all geeks here might as well talk about the minutia.

The PoC basically tests that if you create a websocket request that results in non-101 response the socket is closed by the server. That is a side effect of the fix. The way the proxy code works is that on presence of the Upgrade header it first hijacks the HTTP request and dials the target. It then starts a copy loop but reads the first bytes into a http.Response. If the response is not 101 it will exit.

The a side effect is that it just so happens to be that because the connection is hijacked the golang server will not reuse the TCP connection and will close it. But according to the HTTP spec that TCP connection is still valid for reuse so the server does not have to actually close the connection (but it happens to). Where this PoC could fall apart is if you are running kube-apiserver behind a particularly pedantic LB (ALB might apply here). Most LBs will not reuse any TCP connection that had an Upgrade header in it, but if they are smart and read the response they can if it didn't result in a 101. From that perspective a load balancer (or reverse proxy) is not obligated to close the TCP connection to the client.

To fully test the vulnerability you need to find a pod you can exec to and another pod on the same node you are not authorized to exec to. First send a malformed pod exec and get the open socket. Then send another request using the kubelet API to exec to a pod you are not authorized for. Then see if you get a valid response (which I believe is a callback URL for the actually tty stream).

The PoC is still basically valid because it could just give you a false negative that you are vulnerable (not a false positive all is swell).

This article is just an opinion piece and junk at that. If they have any data they fail to properly cite it beyond their own economist article which also fails to properly cite sources. I find this so frustrating when reading articles these days. All to often they just write "in a recent study ..." with no mention of what the study is, who did it, or a link for you to read it.

Suicide is a huge problem and very complex topic and this article answers to "Why" are quite flippant.

Your assuming the government made the city desirable. An argument can be made that geography made the city desirable and government made it less.

Right, if people who live there want to prevent apartments from being built, that will drive up costs. Why does that need to be prevented? Why is the lack of affordable housing a crisis?

Eventually it seems the market will level out. If people can't afford to live there then industries will leave. At that point people living there will have to decide if that's okay or they should change policy to be more accompanying.

I grew up in LA and left because it was unaffordable. So I don't understand the "crisis." Why can't people just move. Seems like the crisis is that maybe people have no mobility and are forced to work in over priced cities. But I don't understand why that is the case.

Can some explain why affordable housing is a problem that requires government policies to prevent? For example, I can't afford a home in Malibu, so I don't live there. I don't understand the issue. Why does government need to step in and fix this?

I happen to be one of those vendors. I don't really view it as a good thing though. It's not good if everybody has to buy different forks of Kubernetes from vendors.

A point of reference, Amazon EKS only runs 1.10 which will not be supported by the community in 3 months. So not all managed services are really keeping up.

In practice most people do not run k8s upgrades through a CD pipeline. They are much more conservative about it. This is not a technical issue, just a cultural one mainly. People plan and roll out upgrades. Most organization treat a cluster as a large pet. They would like to avoid upgrading if they can because it's viewed as a risk. Patch releases are not typically an issue, it is minor releases that cause concern.

So every 3 months is too fast for a lot of teams (again, not technical issue, this is culture of enterprise) so they may put off an upgrade. Once you do that the upgrade becomes more risky because there is obviously more change from 1 to 3 than 1 to 2.

What I'm describing is not an issue specific to k8s, this is just a general enterprise infrastructure issue and one of the many reasons enterprises like LTS releases.

It's about time for a Kubernetes to do LTS releases. 3 month release cycle and support for only 9 months is too quick for companies given that in practice companies are running lots of clusters, not just 1 or 2 big clusters.

I'm working on some pretty massive things right now. I should have something to show December (DockerCon EU) time frame. It's all in the area of state management. This is something I've been working on for quite some time. The hardest part of an orchestration systems is the persistent store. I'm working on some patterns to effectively remove the need for database but use only object storage (which is significantly more reliable, cheaper, and easier)

k3s is not intended to be a competitor, but let's say I wanted to build it out to compete with systems. Swarm excels in UX and cluster management. It is easy to run and use. But it is incomplete in features and functionality. So k3s addresses the cluster management issues and has tons of features. It makes k8s easy to run, but it still has Kubernetes UX which is quite difficult. So in the end I think it is a wash between k3s and Swarm. You either get hard to use (k3s) or incomplete (Swarm). I have a different project Rio (https://github.com/rancher/rio) that attempts to address UX (and it's built on k3s). So Rio could possibly be a system that is easy to use, powerful, and simple to run. I think Rio could be something that is better than both raw k8s and Swarm for regular users, but it's a very early.

For sure running k8s is difficult, I don't think anybody would disagree with me there, but of course you can buy GKE. I have to point out that GKE is the only decent k8s implementation, EKS and AKS are not real contenders. Digital Ocean will launch their service, I've seen it and it's good and I hope they do well. But in general you can't really expect the Kubernetes landscape to change much from what it is today, which is basically GKE good, everything else meh. Why? Kubernetes is not really a proven business model for cloud providers yet. It costs the cloud provider more to offer Kubernetes and it not significantly drawing more users in (and consuming more). The obvious example of this is AWS lack luster support and commitment to EKS. If there was a big business opportunity Amazon would be doing more. I have no concrete proof but ECS and Fargate stand to make much more money for Amazon (just a guess). So in general the argument that running on GKE isn't bad I don't think holds up because GKE is the only decent option. DO has yet to launch, but they can't really standup to GKE because you have to look at things holistically. Just running the cluster is like 10% of the whole solution. You need to then figure out how to do authentication, authorization, load balancing (built in service LB and ingress are not sufficient), monitoring, logging, and disaster recovery. Google has a product in each of these areas, but they have 100x more resources than DO. Basically nobody can (or is willing to) put the money into K8s like Google does and Google has yet to prove that their investment is worth it.

That's not to say I don't think Kubernetes will survive. I do think it will survive and it will be around for awhile. Because it's a good fit for enterprise right now. Not a good cloud provider business, not good for small dev shops, but good for enterprise.

Containers have a lot of value. My rule of thumb is basically use containers (docker) and as little as possible of anything else in the container ecosystem. So basically put your app in a container try to not change too much from however you currently do things. There is no shame in running --net=host or just doing "-v /mnt/someebsvolume:/data." I personally like Hashicorp because their tools are simple and grow with you. Besides Hashicorp, I don't have great recommendations for tools. In my opinion the current container ecosystem is a disaster for users. Big business ideas took over and killed innovation. Simple lightweight modular systems all got annihilated by Kubernetes and now it's pretty much a monoculture.

I completely agree. The current trend of orchestration all sells a story of hyperscale like GIFEE. That is not how most people do or should run there deployments (I'm talking about the vast majority outside SV). The operational complexity today is too high. Kubernetes is a big business system, it caters to enterprise. If you aren't an enterprise I would caution you against k8s.

I never intented anyone to directly use it. The "selling point" is what I'm going to put on top of this. This is intended to be an internal library. Hence the stupid puny name.

Easier than you would think. I basically replaced the etcd KV API with a SQL based one. But that means I kept the majority of the k8s etcd3 driver in place which has all of the complicated k8s specific code.

It's a combination of pulling and notification. The sqlite DB table is structured like a log, so clients basically just need to keep grabbing the latest id. In practice it's has proven to work pretty well. The code I have public right now does not support HA, I have a private branch that I'm still testing.

Against Kubernetes? Nothing, it's a beautiful architecture. I just want to use the code and architecture in different ways and specifically with lower resource constraints.

I created this (I'm the Chief Architect and Co-founder of Rancher Labs, I experiment with stuff like this all the time). The purpose of this project is really to embed in another project (https://github.com/rancher/rio is an example) but as a side effect it's a nice little standalone k8s package. I never had any intention to support it as a standalone project, but hey if somebody is interested who knows.

All of the features removed are based off of two basic ideas

1) If there are X ways to do something, I choose the best one (obviously subjective). 2) The features are not commonly used or really shouldn't be in k8s to begin with.

The end goal of what I'm working on is basically to use k8s code as a library to do orchestration. Step one was to reduce the footprint of k8s (I'm 80% there with this project), step two is to completely rework the state management such that you no longer need to persist state in k8s. This is a much larger goal. I've fooled around a lot with the persistence layer in k8s (this project is running on sqlite3) so I'm basically doing a lot of work of figuring what state I can throw away. The theory is that all desired state comes from your yaml files. Actual state is actual (what really exists). Everything else in k8s should be purely derived and not important.

As a technology, I've had far better experience with snap over flatpak. It does bother me though with snaps that it all seems tied to a proprietary store. Does anyone know if it's possible to run the server side components yourself.

It's comments like this that have me coming back to HN again and again.

It has the xmms skin, love it.

I think by the time they figure out what Fedora CoreOS will be, they will have basically missed the boat for non-Red Hat customer adoption.

Basically it will only really matter for people running OpenShift.

I didn't say orchestration provides no value. I've spent the last 15 years building orchestration systems, I believe in them. I'm merely saying the most value of containers is achieved without requiring the adoption of orchestration. What I mean by that is if you take your existing means of running non-containerized apps, and change nothing except putting your app in a container, you will see a large benefit. Now changing your existing means of deploying application and swapping that out to an orchestration engine such as k8s may or may not benefit you. If you have 1000 servers, you will mostly likely see benefit. If you have 20, you might not.

k8s or orchestration/clustering is not the only way to run containers. Amazon knows that. If I was to make a bet I say that Fargate or Lambda have much better chance of being a major money maker for AWS.

It's really true for most users. I've seen it over and over again. Working in SV we lose sight of just how simple many peoples applications are. But I'm not saying just start a server and call it good. Use auto scaling groups, and some monitoring from your cloud provider. It's typically sufficient. Some of the most successful container deployments I've seen just use terraform + AWS services (EBS, ELB, ASGs). Its simple and gets the job done, not a lot of moving parts.

I don't mean to push an anti-k8s agenda. What I'm pointing out is that people have conflated the value of containers with the value of orchestration and clustering. They don't need to go hand in hand. Containers without orchestration has been proven to save money. It's hard at the moment to prove the real value of k8s. It's too early and there isn't enough adoption. When you look at most success cases of k8s they often can achieve the same benefits using an plain old docker and some auto scaling groups.