Hacker Newsnew | past | comments | ask | show | jobs | submit | hardbyte's commentslogin

ty. I'm pushing opentelemetry metrics which we use for alerting. I had thought about emitting PolicyReports from the operator too


pgroles is a declarative PostgreSQL role manager (YAML in, plan/apply out, CLI or Kubernetes operator). This interactive tutorial walks through a few common Postgres permission errors that you might run into.

You run queries against real PostgreSQL 18 compiled to WASM (PGlite). Building up from early broad grants directly on users in the first section through to abstractions around owners, login roles and roles that scope access.


Hopefully clear I'm not trying to take credit for the upstream work!


I think it was clear, yes. Projects like this one seem right in my wheelhouse (if I'd heard of CEL before, anyway) and I definitely appreciate seeing other people do things like this.


Yeah a big motivation for us was avoiding the need to keep another system up to date. Gatehouse basically sits at the execute policy layer, and we let the application code decide how to unify the data (or not).

Oso local authorization looks like a fantastic solution.


You're spot on - we wanted to support some async graph traversal calls similar to the ReBAC example and therefore made the evaluate_access call async. I also wanted to support short circuiting such that somewhat expensive IO calls might be skipped by returning early from a policy that didn't need to make that call.


Nah, I think your intuition is correct it should be broken up.


BYO persistence


Thanks! I'm a big fan of Cedar and DSLs such as CEL and gorules. Hopefully there is a place for a Rust solution as well.


I did put licence = "Apache-2.0" in the Cargo.toml but Partly is okay with it being MIT. Update the repo to explicitly add the license text now. Thanks for the call out


async-friendly Rust native library with decision traceability.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: