Add support for self-hosting? (Caprover, etc)

[derek-adair]

I started using this last fall and it's been very useful. I'd definitely recommend caprover in the spirit of the project.

Caprover

[skoczen]

Thanks, will check it out - haven't heard it! I'm also thinking about building a docker container - both docker compose and snaps have come a long way.

But bigger-picture, I want to make sure that the project isn't making it easy to get wrong. The encryption keys sit in the environment so the app can access them - which makes services like Heroku where there's a full-time team managing the security of the VM more appealing to me than spinning up my own digitalocean container and worrying about security.

It feels like Kubernetes is going to make this a totally solved problem within 3 years, so this project will probably transition over to whatever that is as it stabilizes. But if you or anyone else spots a great project, please chime in!

[derek-adair]

I totally get that. Adding support for caprover is probably a better ask.

The easiest way is to make it into a docker container, then it has basic feature parody with heroku. I will see if i can make a container for you and deploy on my caprover instance.

[skoczen]

So I've been thinking a lot about this since you posted it, and I'm still torn. After looking into caprover, it looks awesome. A simple, drop-in replacement for Heroku that gives a ton of advantages - resources can all be on one machine, portability, cost savings.

Then I see another news story like this one where alpine linux images (which a ton of docker containers are based on) have had no root password.. for the past three years. And that makes me think this project has absolutely no business considering providing a self-hosted option until there's an active contributor with good security credentials who actively works in devops/cloud server management.

I see my own bills on heroku for my inkshop instance and I compare it to non-sensitive containers I'm running on digital ocean, and it kills me a little. And then I think, "If it's not worth the money to keep the data safe, then don't keep the data." The reality is that Inkshop is targeted toward small businesses that are making some money, and have some customer data to keep safe. So I still lean against making it easy to self-host. Even though I'm 100% pro self-hosting in my own life, and live out of a nextcloud instance. It feels complicated.

I welcome any further thoughts you or anyone else has. What do you think?

Going to update the title to talk reflect what feels like the bigger question to me.

[derek-adair]

re that article:
I think this is overstated. For this to matter your docker host must already be compromised, in which case you already have MUCH bigger problems. Hardening your host mitigates this type of vulnerability. That's not to say the current container ecosystem is easily navigable. There are DEFINITELY risks. One being its really... REALLY easy to do things wrong.

There are actually some rather disturbing defaults to Docker in general that make it a nightmare for security. Most people grant root permissions via their docker containers. Again, this assumes the host is already compromised.... still disturbing.

IMO this illustrates the need to take an extra step and make it deployable in a non-proprietary ecosystem. Regardless if you support self hosting or not, someone will try and save a buck and do it (me for example :p). Additionally, you're assuming that heroku does things properly. Unless things have changed the entire heroku stack is rather opaque and that scares me more than any vulnerabilities like this which are 100% in my control.

[derek-adair]

SeleniumHQ has a entire repo for running their softare in containers. I know this is an extreme example of supporting a generic container, but this is something I've been keeping in mind w/ all of my projects.

Docker Selenium

I understand that this is not realistic, but its something to keep in mind for the future.

[skoczen]

That all makes sense.

Security vs Cost

In the save-a-buck category, I think we're going to have to agree to disagree. If someone isn't willing to pay to properly secure their customer's data, they shouldn't have the data. I won't drive this project in a direction that makes it easy for people to compromise their user's data because they were too cheap to pay for security. Of course, someone can do it, and I certainly can't police what people do with an open-source project. But having a one-click setup that follows best practices can go a long way.

If we can find a way to securely and cheaply self-host, awesome. But if the tradeoff is cost vs security, I'm going to pick security every time.

To follow the ethos of the project, I'll explain why with people. Imagine a not-too-distant future where I'm running the Change Monsters or an updated two-year life plan on inkshop. People are using it, putting it their private hopes and dreams, brainstorming things they'd really like to do before they die.

Some of that information is really personal, and it would be catastrophic if it got out.

In running the project, I want to be able to look an actual user in the eye, and say, "The things you put into this system are safe. And, if you want, you can double-lock them so that they're for your eyes only."

That second layer - a zero-knowledge system makes me feel fine about self-hosting. But there is data that isn't (and practically can't be) zero-knowledge encrypted. Things like email addresses and first names and purchase information. That stuff is also sensitive.

Pretend instead of Ink and Feet, Inkshop is powering a site for people to buy medicine. Or things someone would be embarrassed to tell their mom/boss that they bought. Email address and purchase information is sensitive information that we can't take chances with.

That person-centered perspective is what informs my views on security for the project - it has to be stupid easy to do right, and you need to disable like five switches that require you to say "I really know what I'm doing" to get it wrong. Or, put a more funny way, the footnote on this comic.

Now - all of that said, I am again, super for self-hosting and low-cost hosting provided that it can be done with the needed security. I'd love to see it happen for this project! Like SSL everywhere, security is a right, not a privilege, and we should work to make it possible.

Technical - securing the host

Now, on the more technical issues, my concern is on that docker host level - and the much bigger problems it implies.

Hardening a server is non-trivial, and out of the box, AWS, DigitalOcean, etc don't provide hardened containers (if I'm wrong and you can point me to a hardened setup that docker can be run safely within, I'm all ears!)

I have no issues running docker within a secured container (for values of secured that are reasonable for ecommerce, there is no absolute security, etc). My issue is that the encryption keys are sitting in that host container, and that part I don't want to make it easy to get wrong.

Again, if there is a way to spin up a DO/GCP/etc space that's hardened and maintained by a full-time professional, I'm super interested, and would love to pull caprover or something like it in.

But I don't know of any - if you or anyone else does, please chime in!

All of that is what lands me at heroku (or similar). For an average small business, they don't have an IT team, let alone a full-time devops/security expert to manage their self-hosted instance.

Heroku/Salesforce, while opaque, has a team of some of the best people in the world at to secure those containers, and a really strong financial incentive to make sure security breaches don't happen (they'd go out of business.) For the use case I think Inkshop is aiming to take on, paying someone $100/mo to host (comparable products at ontraport/infusionsoft/etc run into $1000/mo) is a no-brainer.

All that said, host container security is also at the edge of my wheelhouse. Most of what I know is from reading the CIS whitepapers and too much server exchange. That makes me unqualified enough that I have questions about my judgment in getting such an important thing right.

Thoughts/feedback welcome!

[derek-adair]

I want to clarify that i'm not trying to persuade you to use caprover for a personal setup for any paid or hosted SaaS version of this.

---

If someone isn't willing to pay to properly secure their customer's data, they shouldn't have the data

I'm willing to pay my time for this, personally. I respect your notion, however, it's really a small commitment to produce your app in a docker container, which is all i'm proposing. My point still stands that if YOU dont personally do this, some one else will. At that point you have no control over the quality of this.

If you look at how the seleniumHQ codebase is structured, they have their docker stuff separate. This allows for focused issue's and more importantly separate and distinct licenses.

---

Again, if there is a way to spin up a DO/GCP/etc space that's hardened and maintained by a full-time professional, I'm super interested, and would love to pull caprover or something like it in.

Personally, i'm comfortable doing all of this on my own, so I guess i sortof projected my personal projects goals onto this one. HA! I will say that this is easier than it EVER has been to maintain. It's fairly trivial to automate a secure setup these days. You could learn to do this in a week over @ AWS and it would cost you hours a month (maybe more if some crazy zero days come about or something).