Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we give every user SQL access to a shared ClickHouse cluster

trigger.dev

Post reply on HN
Print view View original

81–85 of 85 posts

Re: How we give every user SQL access to a shared ClickHouse cluster

#81

Post by staticassertion »

array_key_first wrote: post #80
staticassertion wrote: post #58

Earlier quoted context omitted.

> Your SSO system is a lot of pressure on one control too. Nobody seems to have problems with Azure or Okta or whatever SSO system you use having every key to the kingdom. Some do, which is why they want MFA on the target side as well as on their SSO. But yes, SSO is very scary and there's a ton of security pressure on it. I don't think that's a very good argument for why we should think that every system should only…

Row level security is absolutely fine. Most companies, or at least the ones I've worked at, don't use row level security at all. Instead, the application just accesses the multi tenant database. It's absolutely littered with broken access control vulnerabilities. You have to remember to put the user key and group in every query across the entire application. And then there's dynamic queries and ORMs, which make every…

I have never suggested that there's something wrong with RLS nor that RLS and an application should be mutually exclusive, as I've pointed out multiple times now.

Re: How we give every user SQL access to a shared ClickHouse cluster

#82

Post by array_key_first »

staticassertion wrote: post #81
array_key_first wrote: post #80

Earlier quoted context omitted.

Row level security is absolutely fine. Most companies, or at least the ones I've worked at, don't use row level security at all. Instead, the application just accesses the multi tenant database. It's absolutely littered with broken access control vulnerabilities. You have to remember to put the user key and group in every query across the entire application. And then there's dynamic queries and ORMs, which make every…

I have never suggested that there's something wrong with RLS nor that RLS and an application should be mutually exclusive, as I've pointed out multiple times now.

Right, I'm just saying that, in practice, most web applications don't use it. From what I've seen. So in a relative sense, this is an improvement. And I think that's generally how we should view security. Within the context of the threat model.

Re: How we give every user SQL access to a shared ClickHouse cluster

#84

Post by efromvt »

skeeter2020 wrote: post #40
efromvt wrote: post #6

Earlier quoted context omitted.

As long as you don't deviate too much from ANSI, I think the 'light sql DSL' approach has a lot of pros when you control the UX. (so UIs, in particular, are fantastic for this approach - what they seem to be targeting with queryies and dashboards). It's more of a product experience; tables are a terrible product surface to manage. Agreed with the ecosystem cons getting much heavier as you move outside the product sur…

Personally I think that's worse. SQL - which is almost ubiqutous - already suffers from a fragmentation problem because of the complex and dated standardization setup. When I learn a new DBMS the two questions I ask at the very start are: 1. what common but non-standard features are supported? 2. what new anchor-features (often cool but also often intended to lock me to the vendor) am I going to pick up? First I need…

I actually 100% agree with your for a new DBMS and share your frustration with vendor-specific features and lock-in. At that level, it's often actively counterproductive for insurgent DBs - ecosystem tooling needs more work to interface with your shiny new DB, etc - and that's why we always see anyone who starts with a non-standard SQL converge on offering ANSI SQL eventually.

I think an application that exposes a curated dataset through a SQL-like interface - so the dashboard/analytic query case described here - is where I think this approach has value. You actually don't want to expose raw tables, INFORMATION_SCHEMA, etc - you're offering a dedicated query language on top of a higher level data product offering, and you might as well take the best of SQL and leave the bits you don't need. (You're not offering a database as a service; you're offering data as a service).

Post reply on HN