ffo

It is patched now.

Ok, maybe I remembered wrong. This makes things even worse.

Well as of now the traffic egresses with Cloudflare in Zürich or Bern with the IP 104.28.19.67 :-)

Whops, good catch! There is definitely the link missing. Going to correct that ASAP.

In the meantime: https://zitadel.ch/blog/imo-passkey-in-icloud-keychain/

True :-)

It did change a lot in the last few days. As of now I get some datacenter in Switzerland and Liechtenstein sometimes.

Been there done that. Google flagged my account several times already, with nice captchas :-)

True it applies to other services as well.

I just scoped my IMO to our Identity and Access Management World.

Exactly this is the intention!

You can choose in the OS to use a general location or stick to something in your proximity.

At least in the Developer Beta 2

I think it is still there, even in Edge on Chromium. But still Chrome dropped the hidden support a while ago.

We still have separate laws here. But we are moving towards the EU regulations in small steps.

Well, in the end channel binding would be the best option which really mitigates some threat vectors. For example MITM, secrets extraction out of the browser and so on. But the big issue is that this is not widely supported.

Using the IP as means is IMO nonsense with todays use of CG-NAT, VPN and so on. It does not rely help securing something.

But these are just my 2 cents ;-)

Disclaimer: I wrote the article

What did you see that felt wrong to use GitOps?

True, cost is not the biggest issue. Separation of teams with different velocity and needs on the other hand is.

One API as abstraction with shared processes eases the pain for the people relying on a platform.

You mean EKS needs re-engineering?

Hey we used tectonic ;-) was a great tool at that time. Tectonic did influence some of the concepts around ORBOS. Just think of Tectonic combined with GitOps, minus the iPXE part.

Disclaimer: I am working with ORBOS

You don’t exactly need to run a cluster per service ;-) Instead you can choose to collocate services who belong together and form a „domain“. But don‘t go the route and build the almighty one Kubernetes cluster where all your domains run in one single place.

We are building a cloud-native IAM over here https://github.com/caos/zitadel

It is written in Go and built around event sourcing for a great audit trail. We already support OIDC, Passwordless, RBAC and working on more features each day.

For those who want to run it on-prem we have a kubernetes operator ready in the next few weeks who also manages the database (cockroach).

We run our own service here https://zitadel.ch with a free tier as well

Feel free to engage with us on GitHub discussions.

Well, this is a fresh approach. I really like the way kreya is built. IMO this is simply the most mature GUI client for gRPC!