5 ms·

I see from the links that this is probably borrowing a bit from Postgrest? I've just discovered Postgrest in the past few days and along with Postgraphile it s

by RNCTX 6y ago

I see from the links that this is probably borrowing a bit from Postgrest? I've just discovered Postgrest in the past few days and along with Postgraphile it seems like all of these projects aimed at "getting back to the database" are a good idea, I like it. It always bothered me that the first order of business with any software development framework was to provide a root/admin database connection. It's like, this thing just explicitly said we're supposed to ignore all of the security work that went into making that database software for the past however many decades, and turn it into a dumb storage medium instead. The lasting impact of Firebase is it proved to the world that being opinionated about the database in order to provide good tools is a viable business model, rather than force ORMs onto people to try and appease every different database flavor under the sun. Good luck to you guys, I like the trend.

kiwicopple 6y ago
You're right about PostgREST. See my comments here: https://news.ycombinator.com/item?id=23321132 https://news.ycombinator.com/item?id=23321132 > we're supposed to ignore all of the security work that went into making that database software for the past however many decades, and turn it into a dumb storage medium instead I couldn't agree more
- block_dagger 6y ago
  With containerization and network orch layer, the db often isn’t the best place to enforce access perms.
  - RNCTX 6y ago
    I think that's debatable. A UI without a persistent root/admin connection lingering in the wild cannot leak such a root/admin connection, can it? How many retail corporations have had breaches resulting in huge credit card dumps that would not have happened if they had not been using frameworks with persistent root/admin database connections outside of their internal office network?
pm90 6y ago
I may be wrong about the history of security work on databases (feel free to correct me!) , but I think the security model was built mostly for an age where a single DB would be used by many apps, thus access control at the DB level seemed natural to the DB admins. Today, with managed/containerized DBs and Microservices and share nothing architecture, I’ve seen most apps use their own database instance, in which case the access control stuff seems to be more of an obstacle than useful. e.g. just the other day, I ran into issues because the user used for schema migration did not have access over some tables in my apps database in Postgres since it has table level access control.
- RNCTX 6y ago
  Not every database application is a public facing web application. Think about, for instance, a company's internal customer database (including billing, etc), accessed with internal tools. CSR/Support people need to be able to see billing status but not credit card numbers, for example. Different levels of management need to be able to generate reports, but again not get credit card numbers. For these use cases the opposite is true. The further you take auth and permissions away from the database/devops admins, the more times you're going to need to reinvent auth and permissions boilerplate for every internal tool under the sun. Which is a pointless exercise if none of the tools in question are ever going to be accessible outside of the company's VPN anyway. Active Directory / LDAP are not abandoned technologies, after all.
  - bavell 6y ago
    What are the pros/cons of using entirely different (siloed) databases with uniform permissions instead of a single database supporting granular permissions? Off the top of my head, I'd say security might be improved but ease of use may suffer. Interested in hearing other's thoughts on the matter.
    - carlps 6y ago
      The cons are inumerable. We've been down that road before and the whole world of business intelligence and enterprise data warehousing came out of it. When every functional unit has their own db, how do you answer questions of the business as a whole? How do you deal with data that multiple functional areas need? On top of that, managing a lot of small silos requires a lot more work and resources then the alternative. Eventually you're going to want to bring that data all together and now you have to have data architects and engineers developing etl solutions and then your resulting data warehouse is going to be that singular database you were trying to avoid from the start, with all the overhead of building it and maintaining it on top of all the maintenance of the source silos. See https://en.wikipedia.org/wiki/Data_warehouse https://en.wikipedia.org/wiki/Data_warehouse

by RNCTX 6y ago

kiwicopple 6y ago

You're right about PostgREST. See my comments here: https://news.ycombinator.com/item?id=23321132 https://news.ycombinator.com/item?id=23321132 > we're supposed to ignore all of the security work that went into making that database software for the past however many decades, and turn it into a dumb storage medium instead I couldn't agree more

block_dagger 6y ago
With containerization and network orch layer, the db often isn’t the best place to enforce access perms.
- RNCTX 6y ago
  I think that's debatable. A UI without a persistent root/admin connection lingering in the wild cannot leak such a root/admin connection, can it? How many retail corporations have had breaches resulting in huge credit card dumps that would not have happened if they had not been using frameworks with persistent root/admin database connections outside of their internal office network?

pm90 6y ago

I may be wrong about the history of security work on databases (feel free to correct me!) , but I think the security model was built mostly for an age where a single DB would be used by many apps, thus access control at the DB level seemed natural to the DB admins. Today, with managed/containerized DBs and Microservices and share nothing architecture, I’ve seen most apps use their own database instance, in which case the access control stuff seems to be more of an obstacle than useful. e.g. just the other day, I ran into issues because the user used for schema migration did not have access over some tables in my apps database in Postgres since it has table level access control.

RNCTX 6y ago
Not every database application is a public facing web application. Think about, for instance, a company's internal customer database (including billing, etc), accessed with internal tools. CSR/Support people need to be able to see billing status but not credit card numbers, for example. Different levels of management need to be able to generate reports, but again not get credit card numbers. For these use cases the opposite is true. The further you take auth and permissions away from the database/devops admins, the more times you're going to need to reinvent auth and permissions boilerplate for every internal tool under the sun. Which is a pointless exercise if none of the tools in question are ever going to be accessible outside of the company's VPN anyway. Active Directory / LDAP are not abandoned technologies, after all.
- bavell 6y ago
  What are the pros/cons of using entirely different (siloed) databases with uniform permissions instead of a single database supporting granular permissions? Off the top of my head, I'd say security might be improved but ease of use may suffer. Interested in hearing other's thoughts on the matter.
  - carlps 6y ago
    The cons are inumerable. We've been down that road before and the whole world of business intelligence and enterprise data warehousing came out of it. When every functional unit has their own db, how do you answer questions of the business as a whole? How do you deal with data that multiple functional areas need? On top of that, managing a lot of small silos requires a lot more work and resources then the alternative. Eventually you're going to want to bring that data all together and now you have to have data architects and engineers developing etl solutions and then your resulting data warehouse is going to be that singular database you were trying to avoid from the start, with all the overhead of building it and maintaining it on top of all the maintenance of the source silos. See https://en.wikipedia.org/wiki/Data_warehouse https://en.wikipedia.org/wiki/Data_warehouse