bdesimone

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.

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...

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 :)

Here's a collection of resources you might find helpful.

https://github.com/pomerium/awesome-zero-trust/

Contributions/PRs very welcome.

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.

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?

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.

> 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.

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.

Yes. And you should probably assume that their claims of end-to-end encryption are about as solid as they were for iMessage.

http://blog.cryptographyengineering.com/2013/06/can-apple-re...

http://arstechnica.com/security/2013/06/can-apple-read-your-...

http://www.zdnet.com/apples-imessage-encryption-claims-refut...

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."

Which has been refuted several times.

"Reopened on Novebmer 6"

Is this an early draft?

I am happy to vouch for William who has been driving the Miami meet ups. He knows his Go and is able to deconstruct rather tricky subjects and present them in a way that's easy to understand. You should check out his blog to see what I mean. Better yet, if you are in Miami, come to the meet-up.

I'm not suggesting prefixing.

It's less complicated than what I'm reading here.

* Use a passphrase of at least five random words.[1]

* Keep that passphrases secret.[2]

* Use a password manager like 1Password or Keepass to generate and manage all other passwords.[3]

[1]: Good passwords have high entropy and are easy to remember. For that reason, passphrases are preferred to passwords.

[2]: It's ok to write down your passphrase, but keep it somewhere safe -- like your wallet.

[3]: Password managers prevent password reuse and make life easier. Sync passwords across devices.

for more: http://bdd.io/security , with linked justifications.

Agreed. Adds a bit of peer review to the mix.

Edit2 = Damage control.

Skettios.

What is coinbase doing to prevent this from happening in the future? Both from a customer service perspective, and from a technical one. I want to assume good faith, but I'd also like to verify before doing business with you.

/thread

Dual citizenship does not need to be kept secret in the US.

Unless you are published, a page is enough. Seriously.

The pushback from tech community in the form of these reports has been encouraging. That said, a little part of me dies when I realize the USA has become a government that censors something like the reporting of the quantity of requests.

What's the justification? I'm genuinely curious.

What are you talking about?

My #3 point was not that dietary health isn't important. It IS important. It's as important as cardiology, renal, etc in the curriculum. That it's "only" one week is shouldn't be taken (and is repeatedly put forth as, as the OP did) proof of how physicians don't care/ aren't trained in diet.

What does your rant about saying the hippocratic oath have to do with anything? What does that have to do with the amount of emphasis the modern medical education puts on health through diet? Of course food should be your medicine. Natural plants are also the base for some ~70% of our drugs. It's just not the only tool in the toolbox.

Then you accidentally support my earlier point that the average joe is godawful self-treating/diagnosing based on their own research. Thanks.

EB as a term is new, the specialization is not.

Most here are engineers with a BS/BA. Maybe a MA. And fewer still with a PhD. Not that education is everything, but it's certainly "years specializing."

Compare that to the track of a typical specialist md:

After your undergrad degree you've got.... 4 years in med school. 4-6 years in residency. Plus a 1-3 year fellowship.

Long story short, what's the credible alternative to relying on multiple expert opinions? Are educated (engineers/lawyers/etc) ordering tests based on research they really don't understand on themselves a better? By what evidence?