Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: populate env vars from secret files in docker entrypoint #1512

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

goatfryed
Copy link
Contributor

📚 Description

Docker swarm does only support secrets as files. Nuxt reads env vars automatically and populates the typed runtimeConfig with it. At the moment this is handled in application code, which is repetitive and not deployment agnostic. It also causes issue in frontend only mode, where developers need to setup files.
See an example of current handling in tusd utils

This PR moves this handling out of application code to the docker entrypoint.

All env vars with suffix _SECRETSFILE populate there suffix-less version now with the secret inside the file.
This means, we can configure a docker secret /run/secret/my_secret=super-secret, configure environment variable NUXT_MY_SECRET_SECRETSFILE=/run/secret/my_secret and access runtimeConfig.mySecret=super-secret in application code.

I've not cleaned up the the existing code yet, but I run across this in context of oauth2 config

📝 Checklist

  • All commits follow the Conventional Commit format
  • The PR's title follows the Conventional Commit format

@dargmuesli
Copy link
Member

This topic is security related: it would be great to have @myyxl and you connect on this, e.g. at this year's Hacktoberfest in Kassel. Let me explain ✍️

Storing secrets in environment variables is generally considered insecure: https://blog.arcjet.com/storing-secrets-in-env-vars-considered-harmful/

Now, what I need to be educated on is the possibilities for attacks that end up with some kind of remote code execution inside the container:

  1. how could an attacker print environment variables? Apparently this is easier than file reads - why?
  2. does exporting environment variables in the entrypoint instead of having them set for the whole container change anything about the attack surface?
  3. which file permissions on secret files would lead to which attack surface? which permissions would an attacker have if they got a remote code execution inside the container?
  4. is there a way to read secrets at startup and unmount all secret sources afterwards so that the secret only lives in memory? How would a container need to be configured to not allow attackers to dump the memory?

Here are some suggestions on locking down containers: https://blog.arcjet.com/dont-just-deploy-defend-secure-container-deployments/
@myyxl if you're interested, I'd suggest this for some short presentation at Hacktoberfest on how you made the maevsi containers more secure. I imagine that being valuable and insightful for others 🙏

@dargmuesli dargmuesli requested a review from myyxl October 2, 2024 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants