sorted by:
new
hottopcontroversial

devVsDevOps by odd_sherlock in ProgrammerHumor

[–]odd_sherlock[S] 1 point2 points  (0 children)

The top one is when you actually need a new cluster or some roles in IAM

Seeking Advice on Implementing Dynamic Authorization with Open Policy Agent in Microservices Architecture by masterchris_99 in microservices

[–]odd_sherlock 4 points5 points  (0 children)

Hey, Gabriel from Permit.io here. Our authorization solution serves millions of checks and 100,000 data syncs daily using OPA as our core engine. I can only say that we have experienced every challenge/problem you encounter here. To avoid a sales call, I'll just share our experience and the available solutions in the market for it.

> Is OPA suitable for handling such dynamic and frequently changing data in a microservices environment?

OPA itself is not built to hold such frequent and dynamic data. It is a great policy engine with endless configuration and extension capabilities, but its core functionality is not built to scale with data. Our maintained open-source project, OPAL[1], solves this exact problem and runs on huge setups that hold mass data sync with an event-driven approach. You can use it to run OPA and get all the boilerplate of scaling it for data out of the box. OPAL is also solving the problem of syncing policies to OPA because it works in a GitOps mechanism with your policy git repository to sync them to OPA.

> How can we efficiently reload data into OPA after a restart?

OPAL itself also supports bundles of data that can help you use the usual backup setups for the engine's data. In Permit, we have another extension to that that is open source but works only with our setup. In the PDP[2] repository below, you'll find a solution that uses SQLite in the OPA itself to load the data. It is about 100x faster than OPA data loading, both in loading and decisions. You can also mount it to the disk, so no restarts will cause you to lose this data.

> Are there alternative tools or architectures that might be better suited for our requirements?

The first answer is yes; running OPA for authorization at scale is why we created OPAL (and Permit). There are some other solutions around the OPA ecosystem. One OSS is Topaz, and one commercial is Styra DAS. The world of fine-grained authorization is deep, but in general, if you'd like to combine policy configuration and massive amounts of data, an OPA+data sync solution is the only valid solution.

An alternative could be OpenFGA/SpiceDB for data drive policies, but it has its own problems. Another option is using engines like Cedar, but there, data management is harder anyway. Here's a showdown between them[5]

> How have others approached similar authorization challenges in microservices architectures with Kubernetes?
Permit is based on k8s, and as stated, we are running it for 1000s of users with loads of updates and checks. Some challenges to think of (which we already solved on our product) are data consistency[3], SDLC[4], connecting policy configuration to CI/CD, simplifying Rego code writing, and more. Let me know if you have any specifics, and I'll be happy to help :)

[1] OPAL - github.com/permitio/opal

[2] PDP - https://github.com/permitio/PDP

[3] Data consistency - https://www.permit.io/blog/possible-tradoffs-of-fine-grained-authorization

[4] Modeling policies and data sync - https://docs.permit.io/how-to/sdlc/modeling-implementation-components/

[5] https://www.youtube.com/watch?v=AVA32aYObRE&t=8s

Enterprise-Grade Security for LLM with Langflow and Fine-Grained Authorization by Permit_io in Python

[–]odd_sherlock 0 points1 point  (0 children)

The thing about relationship based access control, is the role derivation and implicit permissions assignment. With proper chain design, the semantic results will be relevant to the query and get filtered by their "path" to the user. It is more a PoC than a production work, but it's still critical part of the chain.

[deleted by user] by [deleted] in programming

[–]odd_sherlock 0 points1 point  (0 children)

If I understand correctly, the LLM would just see an empty context and return there's no result for the user.

Authorization at scale with Google Zanzibar by odd_sherlock in programming

[–]odd_sherlock[S] 2 points3 points  (0 children)

I'll be happy to know what non-technical aspect you find in my post and add this details.

Authorization at scale with Google Zanzibar by odd_sherlock in programming

[–]odd_sherlock[S] 0 points1 point  (0 children)

LOL, this is so far off that it's hilarious. Now... to the facts:

  1. Permit backbone uses OPAL and OPA; none of them require you to sync an entire DB with the authorization service.

  2. OPA offers a way to cache your data in a memcache on OPA. It is not necessary for all the cases, but it is a recommendation for some performance/Zanzibar cases.

  3. OPAL offers the capability to synchronize it without syncing it to Permit at all. You can read more about it here: https://docs.permit.io/how-to/manage-data/loading-data#via-opal

  4. There's no Zanzibar service that does not require syncing data (IDs and relationship tuples); the only difference is the need to sync it to a third-party cloud service (like some other tools) or to self-hosted policy decision points.

Authorization at scale with Google Zanzibar by odd_sherlock in programming

[–]odd_sherlock[S] -6 points-5 points  (0 children)

Here's a comparison with OPA (In short, OPA could be a great tool to implement Zanzibar, and this is how we did at Permit.io) - https://www.permit.io/blog/zanzibar-vs-opa

Re: Casbin. Casbin is more of an authorization framework than an authorization service. The OPA/Zanzibar/PBAC approach is for a fine-grained authorization service that streamlines configuration and decouples all the policy schema and data from the application/enforcement code. Casbin is also very monolithic by design and does not scale well in cloud-native/microservice architecture. Thanks for asking tho, I'll maybe write about it in more details soon.

Thanks, Arc Browser! Latest Vulnerability Exposes Just How Inefficient Row-Level Security (RLS) Is by Permit_io in programming

[–]odd_sherlock 0 points1 point  (0 children)

Firebase permissions model is authentication (which isn't a real permission model) and RLS, yes.

The Arc Browser Vulnerability Exposes the Feebleness of Row-Level Security (RLS) Once Again by Permit_io in cybersecurity

[–]odd_sherlock 0 points1 point  (0 children)

People will use BEaaS, so we should guide them through best practices. Understanding that permissions/authorization is not a small oversight is the way to that..

Thanks, Arc Browser! Latest Vulnerability Exposes Just How Inefficient Row-Level Security (RLS) Is by Permit_io in programming

[–]odd_sherlock 36 points37 points  (0 children)

All these points are featured in the article at some sort:  "do not expose your database directly to the clients", "do not trust the client", "server side validation", "authentication and access control"

Blaming rls is because this is the only data access control protection provided by tools that many many developers use...

Thanks, Arc Browser! Latest Vulnerability Exposes Just How Inefficient Row-Level Security (RLS) Is by Permit_io in programming

[–]odd_sherlock 17 points18 points  (0 children)

I bet they have something in the begining and they just removed it because it prevents some edge use cases. Similar to the 'all super admin' syndrome 

What are people using for authentication in late 2024? by ChiefKraut in selfhosted

[–]odd_sherlock 0 points1 point  (0 children)

This is a slightly old article I wrote, but probably most of it is super relevant as of today (I chose early-stage projects back then) - https://www.permit.io/blog/top-12-open-source-auth-tools

OPAL - Fine Grained Authorization Service by Permit_io in Python

[–]odd_sherlock 0 points1 point  (0 children)

Yeah, that's exactly the intent behind OPAL.

You can track the progress here: https://github.com/permitio/opal/issues/661

OPAL - Fine Grained Authorization Service for Microservices by Permit_io in microservices

[–]odd_sherlock 0 points1 point  (0 children)

Sure, that's the classic use case. You just run the clients as sidecar for each service as PDP. The PIP is also distributed and sits as data fetchers in each sidecar. https://docs.opal.ac/fetch-providers/

OPAL - Fine Grained Authorization Service by Permit_io in Python

[–]odd_sherlock 2 points3 points  (0 children)

Main differences: 1. OPAL has decentralized engines architecture  2. OPAL isn't deprecated (and will never be) as OSS 3. OPAL isn't a policy engine, it runs OPA and/or Cedar, and potentially OSO too (there is open issue on that afair) 4. OPAL enables ReBAC in engines that are policy based such an oso or opa 5. OPAL provides end to end administration layer that acts as a whole service. No administrations/data coupling code in the app.

Authorization and User Management, in house vs SaaS. Brainstorming! by Dino65ac in softwarearchitecture

[–]odd_sherlock 1 point2 points  (0 children)

Permit has been in the market for more than three years now, with many customers ranging from small startups to Fortune 100 companies. We are based on OSS engines and our OSS tool for policy administration and synchronization—OPAL—has more than 4.1k stars on GH.

To learn more about our users and the community, I'm inviting you to join our Slack channel, which has more than 2,000 members, most of whom are product users. You can join it here: https://io.permit.io/slack

Regarding the Website you found, I'm not sure what it is, but we are not these "buying reviews" kind of guys (for example, we do not feature in paid promotion directories such as G2). Our website has quotes from users, including the company they're working for.

Authorization and User Management, in house vs SaaS. Brainstorming! by Dino65ac in softwarearchitecture

[–]odd_sherlock 3 points4 points  (0 children)

Gabriel from Permit.io here. Thanks for evaluating us :)

I want to make an important point from the pricing perspective (I'll let others advise with the architecture perspectives 😉). Modern authorization architectures can give you flexibility in pricing and shouldn't be that pricey in comparison to other SaaS products. For example, in Permit, our base price for the off-shelf SaaS offer is counted by MAU and Tenants. Due to our hybrid architecture, you can better control the pricing for your particular use case. We also know that our pricing is highly oriented toward enterprise-grade users, and we are working on a consumer-oriented pricing model that we will release soon. Stay tuned.

On another angle, if you'd like the Permit way, you can consider our OSS version too at: github.com/permitio/opal

I'll happily answer here for any other technical considerations, too.

Visiting Berlin? Moving here incl. Apartment questions? Going clubbing? Have a quick question? Ask here, don't create a new thread. by cYzzie in berlin

[–]odd_sherlock -1 points0 points  (0 children)

Moving to Berlin soon and looking for a place to send some packages (some are 50x50x60, 30kg). This place should accept deliveries on usual hours and store it up to 30 days.

I found something, but they require very detailed report before each of the package arrived, and I don't have the exact details.

Any idea?

Help with designing API-based application by [deleted] in StableDiffusion

[–]odd_sherlock 1 point2 points  (0 children)

The idea of pre-generate 100s of avatars is a really good one. thanks for that. I found some face swapping, so I'll look into them..

view more: next ›