Posting a coworker’s deep dive on the nuance of health checks that actually represent readiness. If you’ve had pods say "ready" while still failing traffic during rollouts, this will resonate.
Happy to answer any questions about the finer points of readiness checks in Pomerium, Envoy, and in general for systems running in systems like k8s, systemd, and so on.
FWIW, I'm very happy to see this announcement. Full MCP support was the only thing holding me back from using GPT5 as my daily driver as it has been my "go to" for hard problems and development since it was released.
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.
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:
I 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. Honestly if I had the right to give you my opinion, I'd just advise you to go back to full custom Go-based proxies regardless of how overwhelming that might sound. Octelium itself still does use Envoy as an ingress for the BeyondCorp mode to route to the intended Service based on the FQDN, however, Envoy as great as it is for ingress and HTTP-based service mesh purposes especially when it comes to memory/CPU usage under huge load conditions, it really shows weakness when it comes to building generic multi L7-protocol aware (e.g. HTTP, SSH, Postgres, MySQL, RDP, etc...) IaPs where you need to understand L7 for each of these protocols to provide access control, modifications to the protocol specific messages and providing L7 aware visibility. The amount of work you need to do in ext_proc, ext_authz, proxy-wasm, etc... is just ridiculous and error prone due to the extra round trips yet it is equivalent to what you could have done if you owned the entire data plane yourself.
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.
CBC is vulnerable to error oracles if you don't encrypt-then-MAC it properly (without the MAC it's also malleable, which is a game-over flaw). GCM is vulnerable to a bunch of its own misuse issues; it doesn't "use" random nonces, it is conceivably (through not really realistically) unsafe to use random nonces, and if you screw up nonce handling it blows up worse than CBC does.
My point is just, these things all have rough edges.
> I see where this is coming and agree in spirit, but GCM is actually idiomatic Go and implemented through the crypto/aead interface, which does about as good a job as any library at being user-proof.
Good point, and I appreciate the (updated) Kubernetes docs do a pretty good job of telling you what the implications of using aesgcm vs secretbox are.
However, I was surprised that XChaCha20-Poly1305 wasn't recommended. XChaCha appears to check all the boxes you mentioned and is nonce-misuse resistant.
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?
Citizenship is already weird. My wife and I both being born in the US, we are tri-citizens and our descendants will also have tri-citizenship in perpetuity.
It would have been quad-citizenship if Norway allowed for multiple passports.
Any child born on US soil is a automatically a US citizen according to the Fourteenth Amendment. Even the children of illegal immigrants and tourists automatically gain US citizenship at birth.
> Any child born on US soil is a automatically a US citizen according to the Fourteenth Amendment
I wonder how this interacts with 8 USC 1401(b)? That says:
The following shall be nationals and citizens of the
United States at birth:
...
(b) a person born in the United States to a member of an
Indian, Eskimo, Aleutian, or other aboriginal tribe: Provided,
That the granting of citizenship under this subsection shall
not in any manner impair or otherwise affect the right of such
person to tribal or other property;
The 14th says "All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the state wherein they reside". Shouldn't that make the "Provided, [...]" part of 1401(b) not be effective?
I suppose that 1401(b) would still be meaningful in the case where someone is born in the United States to an Indian, Eskimo, etc., but is not considered to be subject to the jurisdiction of the United States for some reason. Then the 14th would not grant them citizenship, but 1401(b) would as long as that did not impair their tribal rights.
That raises the question of when someone can be born in the United States but not subject to the jurisdiction thereof.
I think you might be reading the "provided" differently than the drafter intended. I think you're parsing "provided" as meaning "so long as" or "only when". I think the drafter intended for it to mean "additionally".
I realize that "provided that" in common speech more often means "so long as" or "only when", but "provided, that" or "provided: that" in statutory text could be read as simply introducing an additional and slightly indepedendent statutory provision. I think the comma is significant here for encouraging this reading.
I think the parent commenter knew that, but assumed that the original commenter doesn't currently live in the U.S. If that's the case, getting U.S. citizenship for their descendents could require a more difficult and expensive trip to give birth inside the U.S.
> our descendants will also have tri-citizenship in perpetuity
is probably wrong. If the descendants never reside in the US, they won't be able to pass on the citizenship to their own children unless they traveled to the US just to give birth.
Didn't Apple debunk that debunking themselves in February, when they released the iOS Security doc? [1]
According to Apple, each device's private key is generated locally and never leaves the device, making it impossible to MITM your messages.
From page 20: "For each key pair, the private keys are saved in the device’s keychain and the public keys are sent to Apple’s directory service (IDS), where they are associated with the user’s phone number or email address, along with the device’s APNs address."
That doesn't make it impossible to MITM - Apple still controls the keyserver.
When I ask for nardi's public key, they can give me theirs, I encrypt it with that key and send it. They use their private key to decrypt it, store it, and then encrypt it with your actual public key and forward it along, neither of us any the wiser.
In the very same doc you quote, they also say of iMessage:
"Apple does not log messages or attachments, and their contents are protected by end-to-end encryption so no one but the sender and receiver can access them. Apple cannot decrypt the data."
Happy to answer any questions about the finer points of readiness checks in Pomerium, Envoy, and in general for systems running in systems like k8s, systemd, and so on.