Readit NewsI apologize if my reply was seen as critical in any way. I only wanted to make a difference between Octelium as a complete platform compared to Pomerium (I meant the open source project not the entire Enterprise offering which is obviously a complete BeyondCorp solution) and Ory Oathkeeper as identity-aware proxies. A more technical description for Octelium is that it is for IaPs similar to what Kubernetes is for containers. It simply provides a complete control plane to manage and deploy IaPs on top of Kubernetes itself. In fact, I am a fan of Pomerium and their work (I still remember your great work related to Golang's Webauthn and its attestation-related stuff ~3 years ago) if you're part of the team. Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.
Genuinely, didn't take it that way at all! I don't expect you to be an expert on Pomerium.
> Funnily enough, Octelium started as a sidecar ext_authz svc for Envoy instances to operate as an IaP but I ended up creating my own Golang-based IaP, Vigil, from scratch because Envoy was just nothing but pain outside HTTP-based resources.
That's really funny... we went the opposite direction as the original versions were based on a custom Go proxy. Of course there are tradeoffs either way. Envoy is blazing fast, and does great with HTTP naturally, but has a giant configuration surface area (both pro and con), but we are now having to write some pretty low level filters /protocol capabilities in envoy for the other protocols we support (SSH, MCP, and so on) in C++ which does not spark joy. So I totally feel what you are saying.
Thanks for the kind words, though I am one of the contributors my colleague did the heavy lifting on the WebAuthN side.
Genuinely happy to see the release and where you are headed on the AI/MCP side. If you (or others) are interested, I am trying to bring more light to this model in the spec if you (or others) would like to weigh in: https://github.com/modelcontextprotocol/modelcontextprotocol...
Thank you. I think your description is great but I, as a user myself, might see it as an identity-aware proxy (i.e. something like Pomerium and Ory Oathkeeper IaPs which are great projects) as opposed to a complete Kubernetes-tier platform that does the entire process of remote access, access control, visibility and auditing, user and identtiy management, centralized policy management, etc... from a data-plane and control-plane perspective for an arbitrary number of resources that need to be protected.
Quick note since it was mentioned. Pomerium does support Kubernetes at pretty much every level you mentioned (although I'm not entirely sure what a "a complete Kubernetes-tier platform" means) including:
- "remote access" : https://www.pomerium.com/docs/capabilities/kubernetes-access
- "access control" https://www.pomerium.com/docs/capabilities/authorization
- "visibility and auditing" : https://www.pomerium.com/docs/capabilities/audit-logs
- "user and identtiy management" https://www.pomerium.com/docs/capabilities/authentication to which I'd add device identity as well.
- "centralized policy management": https://www.pomerium.com/docs/capabilities/authorization & https://www.pomerium.com/docs/internals/ppl
- deployments using Ingress Controller or GatewayAPI https://www.pomerium.com/docs/deploy/k8s/ingress, https://www.pomerium.com/docs/deploy/k8s/gateway-api
- "for an arbitrary number of resources" not sure what to link to but there's no limit here
Congrats on the release. I saw your thread on MCP and completely agree with the approach. Happy to trade notes :)
Hey everyone, author here. I wrote this post in an attempt to better understand how cybersecurity evolved to the Zero Trust model, and what that means, practically.
If your organizations have implemented some form of Zero Trust or you are aware of other resources, please comment so I can keep learning.
Here are some resources I found useful for further reading:
https://about.gitlab.com/blog/2019/04/01/evolution-of-zero-t...
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
https://www.oreilly.com/library/view/zero-trust-networks/978...
Here's a collection of resources you might find helpful.
https://github.com/pomerium/awesome-zero-trust/
Contributions/PRs very welcome.
bdesimone commented on Remote access to production infrastructure (death to the VPN) mattslifebytes.com/2020/0... · Posted by u/sullivanmatt
If you are interested in BeyondCorp-style access, I put together a collection of curated resources.
https://github.com/pomerium/awesome-zero-trust
PRs welcome.
bdesimone commented on Kubernetes Security Assessment [pdf] github.com/kubernetes/com... · Posted by u/Tomte
It's "NMR" in the sense that the nonce is long enough to safely use random nonces, you mean? In practice, Kubernetes can use random GCM nonces safely too. Real NMR ciphers don't just have misuse-resistant ergonomics, but also better failure modes when the ergonomics fail: if you reuse a Chapoly nonce, it blows up. That doesn't happen with AEZ or SIV.
I agree that both can be used safely. And, yes to be clear, NMR here means "less likely to happen" not "better able to handle failure." Unfortunately, AES-GCM-SIV (or AEZ) aren't yet in Go's standard lib.
But, why not use XChaCha20-Poly1305 over AES-GCM in Go? Both are "implemented through the crypto/aead" and -- to my eyes -- seem equally user-proof. Why not take the bigger nonce size?
bdesimone commented on Kubernetes Security Assessment [pdf] github.com/kubernetes/com... · Posted by u/Tomte
AES-GCM or even CBC for that matter is not vulnerable/broken. Why did they recommend Secretbox? Is there an implementation error? I am not talking about the potential of making mistakes and using platform supported constructs.
Does it make sense to make this recommendation even if the dev did not choose a vulnerable algorithm and there aren't any issues with implementation?
In the document they say that AES-CBC is vulnerable to padding oracle attacks, and AES-GCM uses random nonces and requires key rotation after so many iterations.
It comes with plenty of warnings, but we all know how much attention people pay to those. I'm confident that the majority of people messing around with things like MCP still don't fully understand how prompt injection attacks work and why they are such a significant threat.
Calling out ChatGPT specifically here feels a bit unfair. The real story is "full MCP client access," and others have shipped that already.
I’m glad MCP is becoming the common standard, but its current security posture leans heavily on two hard things:
(1) agent/UI‑level controls (which are brittle for all the reasons you've written about, wonderfully I might add), and
(2) perfectly tuned OAuth scopes across a fleet of MCP servers. Scopes are static and coarse by nature; prompts and context are dynamic. That mismatch is where trouble creeps in.