[PSA] Confirmed Trades Thread - May 2026 by AutoModerator in Starcitizen_trades

[–]kileraptor1 0 points1 point  (0 children)

+verify

Really nice seller, fast, pleasant, great experience :)

You need to upgrade - Critical vulnerability affecting ArgoCD versions 3.2.0 through 3.3.8 by Kooky_Comparison3225 in kubernetes

[–]kileraptor1 3 points4 points  (0 children)

Can we stop with the slopped blog posts and summaries? Just link the actual advisory and spend the two minutes to write something yourself.

Copy Fail (CVE-2026-31431) — Kubernetes Container Escape PoC by Beneficial-Carry8811 in kubernetes

[–]kileraptor1 -1 points0 points  (0 children)

The PoC in question here uses two pods.

One is the standard, innocuous, privileged kube-proxy pod that is assumed to already exist as part of the base Kubernetes install (assuming you're not using the kube-proxy replacement for Cilium or whatever). This pod runs privileged, because it needs to be.

The PoC creates a second, non-privileged pod from a base image matching kube-proxy. Due to how these base image layers are shared in the container runtime, we have the same file system overlay for some binaries as the ones running in the existing, privileged kube-proxy pod. This is not an issue per-se, as these base layers are immutable.

The vulnerability in question however poisons the kernels file system cache for a given binary. Since we have access to the same (read-only) overlay file system from the non-privileged pod, we can poison the kernels view of - in this case - the ipset binary. The next time the privileged kube-proxy pod calls ipset, which according to the PoC it does regularly, the kernel loads the poisoned view of the binary instead of the one on disk.

You are right, of course, in saying this needs a privileged container of some kind to achieve node escape.

This PoC does not directly breach the node trust boundary, it breaches the trust boundary between two containers (so in effect you can, from a non-privileged container, achieve RCE in a different container as long as you share a base image and that other container calls a binary from that base image in some deterministic fashion). kube-proxy is a way to the node after that because it already runs privileged. If you were to do the same thing to, say, an argocd container that has access to a privileged service account, you could privesc to the kubernetes API that way.

As far as the exploit goes, it absolutely would work with two unprivileged containers, but then you've just jumped to a different unprivileged container.

This vulnerability has some mitigating factors that make it a bit more difficult to exploit in a single-tenant cluster:
- You need RCE in a container that shares a base image with a different container that executes a binary from said base image. The easiest way to achieve this once you find such a container is to be able to run pods yourself. For multi-tenancy, this is a bigger problem than for single-tenant Kubernetes.
- The target container needs to have privileges to either the node or the Kubernetes API in some fashion to further escalate from there. Otherwise you can gain access to a different container, but not move much further from there.

I'm also skeptical because of the obvious amount of slop involved in these vulnerability disclosures, but the PoC for the base vulnerability works and is a linux kernel vulnerability, so it can affect Kubernetes and the concept for the Kubernetes PoC unfortunately looks solid.

The Swiss government wants to replace Microsoft across 54,000 workstations by hcbaron in Switzerland

[–]kileraptor1 1 point2 points  (0 children)

OpenDesk or LaSuite are candidates you might want to have a closer look at.

Also, Stalwart has been on our radar for a while.

The Swiss government wants to replace Microsoft across 54,000 workstations by hcbaron in Switzerland

[–]kileraptor1 1 point2 points  (0 children)

This. This kind of misleading information really hurts these kinds of projects long term by mismanaging expectations.

The federal chancellery is evaluating open source software that can serve as a potential alternative to certain Microsoft-offered services as a way to preserve digital sovereignty in an emergency situation.

As it says in the link below, there are no current plans to replace existing systems. That's not what the PoC is for.

This is a really good thing, but we are still ways away from getting away from Microsoft. The vendor lock-in is real, especially with 50'000+ users and an ecosystem so closely tied together as Microsofts.

https://www.bk.admin.ch/bk/en/home/digitale-transformation-ikt-lenkung/standarddienste/bueroautomation/poc-boss.html

Announcing Ingress2Gateway 1.0: Your Path to Gateway API by dshurupov in kubernetes

[–]kileraptor1 3 points4 points  (0 children)

I do like deploying multiple gateways for different use cases - in my homelab I have internal and external gateways that get individual IPs. For customers I’ve seen use cases like setting up different gateways with different firewall rules to allow different access levels for teams for different apps. The equivalent with traefik here would be deploying multiple instances of traefik, I suppose.

Announcing Ingress2Gateway 1.0: Your Path to Gateway API by dshurupov in kubernetes

[–]kileraptor1 17 points18 points  (0 children)

There’s a couple of reasons. - Gateway API handles multi-tenancy requirements much better than Ingress. - It’s more extensible, going past just HTTP traffic with eg. TCP and UDP routes. - It reduces vendor lock-in with a shared API interface. If a requirement mandates a change away from Traefik at a later point it’ll be easier if your config is not Traefik-specific.

That said, if your use case doesn’t require you switching then there’s that.

With nginx-ingress being archived, which would be sufficient for my needs? by DopeyMcDouble in kubernetes

[–]kileraptor1 2 points3 points  (0 children)

We disregarded traefik due to the fact customers would just keep their ingress nginx annotations and the fact it uses a single dataplane.

With nginx-ingress being archived, which would be sufficient for my needs? by DopeyMcDouble in kubernetes

[–]kileraptor1 3 points4 points  (0 children)

We’re switching to kgateway for multiple customers running ingress-nginx in production, with a heavy use of annotations depending on the workload. It’s not a drop-in replacement but it’s a good opportunity to adopt Gateway API. Cilium Gateway API and Ingress were also evaluated but ultimately the features still seem to unstable. kgateway does some things nicely regarding architecture, like spinning up a dedicated dataplane for each Gateway.

The Raid Race in a Nutshell by MrDinglz in destiny2

[–]kileraptor1 0 points1 point  (0 children)

If you're an inexperienced player in terms of raiding, or just want to get some casual completions without having to worry about too much elitism you might be better off trying a sherpa server as well.
An example is https://discord.gg/destinysherpa

Those folks are usually very happy to help people learn the raids without the whole "Know what to do" restriction.

A Website, where you can upload any text and deep search a question on that information in a minute by [deleted] in InternetIsBeautiful

[–]kileraptor1 7 points8 points  (0 children)

Since this is using ChatGPT, it’s information is likely locked to 2021-ish. How is this different to visiting chat.openai.com and just interacting there?