4 ms·
I would never use this as is (sorry). Rolling your own is about the same level of effort, easier to mock/modify/customize as needed. And if I wasn't rolling m
by bluelightning2k 4y ago
I would never use this as is (sorry).
Rolling your own is about the same level of effort, easier to mock/modify/customize as needed.
And if I wasn't rolling my own, I'd look to a library (many in NPM) or I'd look to a Kubernetes sidecar where that makes sense (Dapr or a service mesh).
Going with an API adds concerns about compliance, GDPR, inheriting your entire attack surface, inheriting your downtime risk, configuration foot-guns, and cost.
But I don't like leaving negativity - so here's some suggestions which might tip the value:
- Having really high quality RBAC front-end UI that I can just let you deal with it
- Same for inviting people to join accounts
- Testing utilities, so it becomes really easy to run the same tests with different permissions
- Similar to the above but a browser extension where a superuser can switch to emulate any other user (or admins can switch to any user in their org if policy allows)
- Audit logging and customer facing UI for viewing audit logs
- kkajla 4y agoReally appreciate the balanced feedback. I don't quite agree that rolling your own authz is that simple (especially fine-grained / resource-based authz), but I understand your other concerns, and we'll work to address them. Also, you have some excellent suggestions here, and we'll incorporate them into our roadmap. Thanks!
- orweis 4y agoThis launch and discussion is pretty exciting! I have to say I really connect with your feedback, I had exactly the same thoughts when building Permit.io: the K8S sidecar (called PDP) and frontend management experiences on top (RBAC, audit logs, invite s, ...) Are really at the core of it.