Yeah, you can do every access control as same as postgres. Since, inspektor uses OPA, you could write policies like give permission to the support engineer only if the engineer is on call.
Inspektor is not included in the postgres; it acts as a proxy between enduser and database.
Next, you can monitor all the operations that have been performed on your postgres instance. SSO logins helps to get the database credentials for data scientist in no time by pulling all the roles from the access directory.
In future, we are adding support for more databases and data warehouses for centralized access control and data masking to get realistic data for the data scientist to create models.
Still, we are in the early days. I hope we can do more with inspektor than simple access control.
Please let us know if you have any idea how we can improve.
Sounds cute. I’m a little curious why it’s written in a mix of Go and Rust. Is the control plane in Go and the data plane in Rust or something?
(I suggested removing the devops tag because this doesn’t do anything devops-y, there’s no deploying or containerising or anything that resembles configuration management.)
I would argue that this is a problematic design. It adds a proxy step for your pg connection; it shifts access outside of postgres or your application, inducing another integration point for your authZ system.
I would probably look into something like authzed for the application, then relevant team permissions are driven into the database from that.
I thought about enforcing it at a centralized place. There are times, we may need to give access to people for adhoc jobs. eg: uploading csv. That time we may use this.
But anyways, problem can be solved in multiple ways
Maybe I’m missing something, but RBAC and RLS in Postgres does everything this does(and more?), and is already included in PostgreSQL.
Yeah, you can do every access control as same as postgres. Since, inspektor uses OPA, you could write policies like give permission to the support engineer only if the engineer is on call.
Inspektor is not included in the postgres; it acts as a proxy between enduser and database.
Next, you can monitor all the operations that have been performed on your postgres instance. SSO logins helps to get the database credentials for data scientist in no time by pulling all the roles from the access directory.
In future, we are adding support for more databases and data warehouses for centralized access control and data masking to get realistic data for the data scientist to create models.
Still, we are in the early days. I hope we can do more with inspektor than simple access control.
Please let us know if you have any idea how we can improve.
Sounds cute. I’m a little curious why it’s written in a mix of Go and Rust. Is the control plane in Go and the data plane in Rust or something?
(I suggested removing the devops tag because this doesn’t do anything devops-y, there’s no deploying or containerising or anything that resembles configuration management.)
Yes correct, control plane is in go and data plane is in Rust :)
@pushcx I wanted to suggest a title removing
GitHub -from the title but I’m not seeing a button to do that. Is this a bug?To avoid edit wars, it goes away after user suggestions change the story once. I’ll fix it.
I would argue that this is a problematic design. It adds a proxy step for your pg connection; it shifts access outside of postgres or your application, inducing another integration point for your authZ system.
I would probably look into something like authzed for the application, then relevant team permissions are driven into the database from that.
To my understanding. authzed do the policy decision whether the user has access or not. But it doesn’t rewrite the query or enforce the decision.
Let me know if I’m understanding is wrong. I am happy to change the design if something is better.
Bluntly: I would place the authorization in the application, not in a proxy enforcing it.
Got it.
I thought about enforcing it at a centralized place. There are times, we may need to give access to people for adhoc jobs. eg: uploading csv. That time we may use this.
But anyways, problem can be solved in multiple ways
cheers