Onpremise: Dont store secrets in docker images

[trondhindenes]

it looks like the example deployment promotes building a docker image containing a config file with potential secret (passwords) in it. This is considered an antipattern and should be avoided. It would be better if it was possible to specify all settings using environment variables or Docker's recommended "/run/secrets" fs dir so that secrets are kept outside the docker image.

[BYK]

Hi @trondhindenes, thanks for the heads up. As the images are built per instance, we think this is fairly safe and not worth all the complexity that comes with using secrets. What do you think?

[trondhindenes]

thanks for replying,
That might be, but it makes the repo next to impossible to use in a real-world production setup (e.g. existing kubernetes cluster or docker swarn cluster or any other orchestrator). IMHO an important part of implementing docker support is the standardization it offers. By using custom on-host image builds and strange bootstrapper scripts, you take that away from users. There's nothing in Sentry that suggest it couldn't run nicely in a kubernets cluster (or docker swarm cluster) - all that's needed is to use container's standardized methods of injecting config/secrets, which are typically environment variables and/or volume maps such as /run/secret.

The current implementation forces users to stand up a specialized "sentry host", eliminating any investment made in container infrastructure. The specialized "bootstrap script" makes it unnecessariliy diffictult to integrate all of this into a standard deploy pipeline.

I don't understand why.

[BYK]

@trondhindenes the aim of this repo is to provide an easy-to-start sample Sentry setup, mostly oriented towards small or development environments. For larger deploys we always encourage people to use our SaaS offering at https://sentry.io.

I'm also sorry to hear you find the install script strange as I tried to make it easily understandable with comments and sections. You'll see that it is simply a convenience script, not a hard requirement. We are also not barring anyone from working on Docker Swarm or Kubernetes deploys, it simply is not our focus or intended audience.

[trondhindenes]

Gotcha. If it's only meant as a sample/poc, then my comments are less valid ofc. My impression was that it was meant as Sentry's recommended setup for an on-prem install.

[BYK]

My impression was that it was meant as Sentry's recommended setup for an on-prem install.

It is, but we don't recommend on-prem installs for large deploys. That's why we have the SaaS service and the single-tenant options as it will become a hassle to manage all these, especially upgrades. We can easily do continuous deploys and then rely on that for dual writes for uninterrupted service during transitions. With the step-upgrade nature of the on-prem installs, a down time, hopefully short, is inevitable due to various migrations.

I'd still want to improve this repo for best practices so if you have specific things we should improve (such as this secrets recommendation), please keep them coming.

[trondhindenes]

if its meant for smaller deploys, all the more reason to build in such a way that it plays nice with existing infra, instead of requiring dedicated hosts. If an org has already made investments in docker swarm or kubernetes, it would be better to allow them to use that than to force standing up a specialized "sentry host".

In any case, I didn't mean to turn this into a long back-and-forth, I just thought it was a unusual way of using docker. Thanks for considering my comment about storing secrets inside containers. Imho If Sentry could be made more compatible with env-vars and/or /run/secrets it would be way easier setting it up in whatever way suits a given org.

Feel free to close this.

[donbeave]

@trondhindenes completely agree with you, probably everybody who uses Kubernetes will think in this way.

[ayozemr]

@trondhindenes the aim of this repo is to provide an easy-to-start sample Sentry setup, mostly oriented towards small or development environments. For larger deploys we always encourage people to use our SaaS offering at https://sentry.io.

Just to put another case where this suggestion is important for prod envs. We are looking to setup this on premise because we are a healthcare company with PHI data in prod and Sentry refused to sign a BAA, forcing us to move out of SaaS Sentry. So there are real cases where companies have to use Sentry on premise in production, and having all secrets by env is the norm.

Hope it helps!

[notpushkin]

Here's my little attempt at running Sentry inside Docker Swarm: https://gist.github.com/notpushkin/d8994b57f3010520118d714da3fd4f09
It's really simple and only includes barebones Sentry with dependencies, but with little work it can be extended back to the full functionality getsentry/onpremise offers.

[martinspaeth]

Hi, thanks for the constructive discussion! We rely on an on premise installation for the same reasons as @ayozemr . We run the setup in production described here and have the same problems regarding deployment. While searching for alternatives I came across the Helm Chart https://github.com/sentry-kubernetes/charts

This is also the install chart which is referenced by Gitlabs managed apps. As far as I understand (I'm not yet so familiar with k8 and Helm) the scripts that have to be executed on the host with the Docker compose variant are implemented by hooks.

Is the Helm variant the preferred installation method?

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Accepted, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― _Ella Wheeler Wilcox_ 🥀

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Accepted, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― _Ella Wheeler Wilcox_ 🥀

[BYK]

I think with #407 and #834 we have gotten as close as we can. We have no plans to work on this in the near future but will accept pull requests that improve the situation without introducing breaking changes.

Thanks everyone for the great discussion!