However, LLM generated code will often, at least in my experience, avoid raising any errors at all, in any case. This is undesirable, because some errors should result in a complete failure - for example, errors which are not transient or environment related but a bug. And in any case, a LLM will prefer turning these single file errors into warnings, though the way I see it, they are errors. They just don't need to abort the process, but errors nonetheless.

I live in such a country and have parents with older phones who can't use esims, so the value is obvious to me. :)

Another poster touched on another important point: it's important for this to be changeable independent of the code. The reason for this is actually kind of subtle. Obviously, you don't wanna have to need to rebuild in order to regenerate permissions. But the real reason, imo, is that it should be easy to parse for a human, easy to locate for a human, and also easy to parse and adjust for a machine, that might determine a permission is no longer necessary, or who is trying to build a dependency graph in order to determine who to wake up during an incident. That means it should go into configuration that is versioned and deployed alongside the code, but not in the code.

If you make this hard to understand and change, people will just copy it, and the you're back to square one. It's gotta be the easiest thing to do the right thing, because at scale, people are gonna do the easiest thing.

I feel like I'm kinda going on at length about this, so instead I'm gonna leave you with a link to a blog I wrote about the same concepts, if you wanna read more. It's about Kubernetes network policies, but really the same concepts apply to all kinds of access.

https://otterize.com/blog/network-policies-are-not-the-right...

Comments URL: https://news.ycombinator.com/item?id=40173191

Points: 9

# Comments: 4

https://news.ycombinator.com/item?id=39761114

The Network Mapper can export to Grafana Tempo (contributed by the community!), but doesn't have to. You can get its output as text, JSON, PNG or SVG using a CLI or an API (directly from the deployment in your cluster), and use it to auto-generate network policies.

Built while avoiding eBPF and reliance on a particular CNI with the intention to run on older nodes, with low privileges, a low performance footprint, and most importantly - zero config.

Comments URL: https://news.ycombinator.com/item?id=39761114

Points: 6

# Comments: 1

This is a bit of a shameless plug, but I hope since it's an open source project it's okay. I'm working on a suite of tools called Otterize (otter and authorize, get it, haha :) that automates workload IAM for Kubernetes workloads.

You label your Pods to get an AWS/GCP/Azure role created, and in a Kubernetes resource specify the access you need, and everything else is done by the Otterize Kubernetes operators so that your pod works.

It's a lot simpler than all the kungfu you normally have to do, but it's not magic, honestly, it's just the result of limiting scope and having an opinionated view of what the development workflow should look like. Basically, instead of maximizing on capabilities, it trades some capabilities to maximize on developer comfort.

Check it out if you're keen on contributing, or just think IAM has a tendency to devolve into a mess ridden with politics.

github.com/otterize/intents-operator and docs.otterize.com

Comments URL: https://news.ycombinator.com/item?id=39694994

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38302531

Points: 3

# Comments: 0

We’ve just added a CLI that creates a graphical map of your cluster using graphviz: otterize network-mapper visualize.

I’m curious to learn: Is such a map valuable to you? How would you use the information? Do you already have a map of your cluster, and was it difficult to acquire?

Comments URL: https://news.ycombinator.com/item?id=35263356

Points: 7

# Comments: 0