Production debugging #561
Unanswered
HubertBubert
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I'm a new to OpenFGA and I'm evaluating the project. I need your help.
My concerns are related mainly to fixing production problems.
If any of my statements are incorrect, I'm sorry. Just please correct me.
So in case of production security problems we can have two main classes:
What is common for both of these problem classes is, that in case of any of them we cannot revert recent changes using 'one click revert' and quickly go back to the last stable version. We can do this in case of policy type authorization, as policies are represented as code. But in OpenFGA we have a live ruleset composed of tuples. And this live ruleset is equivalent of policies (everything what is external is represented as contextual tuples and conditions).
What is the problem with this live ruleset?
It cannot be reverted to the previous stable version. So in case of any security problems we need to be able to quickly debug a security misconfiguration.
There is authorization model abstraction which is represented as code and we can switch between authorization models on production, but this does not solve anything really. When there is a tuple in the ruleset which causes the problem and is compatible with the previous model, it still affects the check, even after the application switched to the previous authorization model.
So the bottom line is: in case of problems we need to quickly debug what is the root cause of security misconfiguration and fix it.
Now, the first mentioned scenario is less severe. And we usually know why someone should have access.
What we can do is to check the existence of expected tuples using
fga tuple read.And here is the first minor problem, it does not accept the authorization model as parameter. Even though the tuple is returned you need to check if this tuple is actually used by the model your application uses. Not very convenient.
In case of the second scenario the situation is much more critical. The users who has access to some confidential resources can cause critical data leak or even data corruption. So in this case it is super critical to fix this ASAP. As I mentioned earlier we cannot do this using one click revert. We need to debug. And here is the big problem. OpenFGA does not give anything really useful for this most critical issue.
What we can do is to use
fga query expandand go up the tree. But this could be super inconvenient if there are multiple levels and multiple rulesets on each of them.Something like
fga query check --explainwould be awesome, as it could return the actual tuple chain which leads to user access.But there is nothing like that and it means this class of problems can be super hard to debug and fix.
And this is the biggest concern I have.
I think fixing authorization problems is critical. Any solution production-ready MUST give tools to quickly address problems.
So am I missing something?
If you're using OpenFGA on production, how do you cope with such problems? Do you need to use some external tools?
Do you build your own tools? Or maybe OpenFGA has everything covered and I'm missing something?
have a great day,
Hubert
All reactions