if `CALENDSO_ENCRYPTION_KEY`and `NEXTAUTH_SECRET` ...
# docker
j
if `CALENDSO_ENCRYPTION_KEY`and
NEXTAUTH_SECRET
and
DATABASE_URL
are required build-time variables and, therefore, baked into the docker image…. would it be possible to extract them from the docker image?
any thoughts on this @Colin - Krumware?
c
I don't think they're baked in, I need to verify
j
thanks for the helpful info!!
c
They may be used in the build to seed encrypted passwords
j
ok. yeah…. trying to decide if i hosting a custom-configured docker image in a public place is a security risk or not
c
But I think that was removed as well
There is both a server and static files in the image. Secrets certainly should not be baked into the static files, but they might be available if the container itself is compromised like in any other container
j
if i host a custom-built docker image, e.g., on dockerhub, would it contain these secrets?
c
It's possible, if you share your image publicly, which you shouldn't do
Again, I don't believe they are baked. But I will do another check.
For what it's worth, I use the public image that's built with the dummy variables, and supply different values for those variables at runtime
j
i would do that, but it seems like that’s not recommended in production?
(i actually have a working docker compose setup i customized but just noticed that blurb on the readme today, so have been spending the evening building a custom docker image 😅)
c
That's mostly a statement to eliminate liability at this point, and hopefully will be removed soon
j
ahh ok.. so if the application passes basic sanity tests after deploying from docker compose… probably good?
c
Yea you should be in good shape just running the public image
But definitely feel free to run through it and point out if you find ways to compromise variables through injection or other means
The image is due a thorough inspection before we introduce true prod recommendations
If you're running multi instance then I'd also recommend you enable sticky sessions at the load balancer (but I don't know how in depth your setup is)
I'm running this in a more complicated k8s deployment
j
ahh thanks for the heads up, but this is just for me on my personal portfolio site. i don’t expect high traffic.
c
Oh yea definitely use it for that. The public image should be great
If you're developing custom plugins and stuff then you might need to roll your own image
But out of the box stuff works great
j
i do have one concern with building from the public image… it seems to be pegged to the latest commit
c
Yea it's running on latest/canary
Version tagging is coming shortly (maybe by end of week, nudge nudge)
j
nice! glad to hear.
appreciate all your work on this! (i’m basically building something much like your link above…. i’m also a consultant 😄 )
c
But it doesn't magically update unless you re-pull the image and start the container, but new builds go out nightly
Haha yea that's why I shared it, same thing, public image runtime config
I needed it so that's how I got here haha
j
sure. for now, i need to build a custom image (because i want to use a PR that’s not yet merged… also, stick to a release tag and not use latest). but sounds like in another week or two both of those will be solved. 🎉
awesome. appreciate all your work.
c
Ah perfect, yup, custom is the way to go there