clayheaton commented on PR #27434: URL: https://github.com/apache/superset/pull/27434#issuecomment-2016474888
I don't mean to derail this to my specific use case, though I appreciate and agree with most of your comments. In fact, the org is working on an internal k8 deployment platform, though it may be a while before it is ready, and the features available on it are not yet published. The company handles a lot of PII. Like many companies, there is a tier of BI analysts who mostly handle scrubbed data, there are those who handle sensitive financial data, and there are teams who work with all of the data. Some of the latter are legal, customer support, and security, others are marketing, business dev, etc. in a targeting role. As a company based in the EU, there is a huge emphasis on data security because of the GDPR. In my experience, this is relatively common, even for companies based elsewhere. That is to say that there really is no such thing as a "lower tier" of internal application because all applications are views as exposed surfaces from a security standpoint and are considered to increase the potential risk for having malicious actors gain entry to then intranet (which is an ongoing usually-detectable threat). A sufficiently bad breach could threaten the company's existence. From a security hygiene point of view, this is a good thing because it encourages good habits. Were it easy enough to do, we should all strive to use valid SSL certificates on servers that are properly configured and have encrypted secrets. These are disparate pieces of tech and getting them all to work well together can be a challenge, as you know. With regards to Superset, my opinion largely has two simply layers: 1) It should be as easy as possible for as many people as possible to get it up and running 2) in a reasonably secure manner that has a clear upgrade path for patching security vulnerabilities. Getting it running often might initially be for prototype purposes, though hardening it for a simple production deployment ideally should be a straightforward and/or well-documented step. Whether that is with docker compose or k8 does not matter much as long as it can be achieved on accessible hardware. To hop back to what I said earlier in this thread, I don't think Superset is far away from what is needed to support these use cases. There are plenty of teams in the world that will be able to clone the repo and fully customize their setup without any handholding. There are teams that simply with sign up with Preset (or Tableau or PowerBI) and outsource the problem. Then there are the teams (of all sizes) who are going to want to self-deploy and need a well-documented (opinionated is fine) secure way to do it. Remember how Wordpress became all the rage in 2004 or so and then became the vector for countless hacks? There are basically two approaches to avoid that: make it so the software is too difficult for an average person to get running on their own or provide the clear route and documentation to deploy and maintain in a manner that reduces the chances of that happening. This has always been one of the lessons that Discourse took to heart, resulting in software that is remarkably easy both to deploy and to keep up-to-date. <details> <summary>Discourse Admin page screenshot</summary> <img width="654" alt="Screenshot 2024-03-23 at 7 58 51 AM" src="https://github.com/apache/superset/assets/205364/ac99c76d-bb56-418e-9769-ddaad2d1b17d";> </details> Over the years, I've worked in various roles in game development. I recall from the late 1990s, in my first role, when people would want to come in a pitch game ideas to us... one of the lead designers told me before a pitch meeting: "A document is fine, a picture is worth a thousand documents, but a working prototype is work a thousand pictures." That's been an excellent lesson for my entire career; instead of telling somebody what you're going to do, actually do it in a prototype capacity and then explain to them how to make it a reality. There's such a hunger for high-quality BI and data visualization these days. Superset is _so close_ to being a platform that is easy to stand up and show as a prototype, though I'm of the opinion that it's just a little bit too hard to deploy right now. ...and then comes the biggest problem of them all, regardless of business size: software meant to be only a prototype ends up in production usage and suddenly you've got a problem because it wasn't deployed in a way to fit that intention. This is where it absolutely matters that it can be secured easily and that people who don't normally deploy production software have access to opinionated resources for making it happen. Apologies for this being too long and rambling. I haven't had enough coffee yet. :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
