Secrets mounted as files

[mroach]

I've been pondering a migration from cloud Kubernetes (deploys using krane) to mrsk.

A feature we use with k8s is mounting some secrets as files in the container rather than as environment variables.

In k8s, you can create a volume sourced from the key-value pairs of a k8s secret. Then you can mount that volume in the container's filesystem, and each item in that secret appears as a file.

containers:
  - name: web
    volumeMounts:
      - name: secret-volume
        mountPath: /opt/run/secrets
        readOnly: true
volumes:
  - name: secret-volume
    secret:
      secretName: my-file-secrets

Now every entry in the k8s secret my-file-secrets appears as a read-only file in /opt/run/secrets. Nice!

The most immediate benefit here is being able to run env and get legible output, and even env | sort. Mostly useful for debugging, of course.
The more important benefit is that there's a size limit to environment variables:

$ true | xargs --show-limits
Your environment variables take up 12755 bytes
POSIX upper limit on argument length (this system): 2082349
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 2069594
Size of command buffer we are actually using: 131072
Maximum parallelism (--max-procs must be no greater): 2147483647

The general concept would be similar to .env.erb where data is generated at deployment time and then available in the running container, so it wouldn't even be specific to secrets.

Does this make sense for mrsk and secret/generated data?

[motdotla]

Doesn't Rails secrets offer effectively the same functionality as this? (in an encrypted file and not affecting environment variable limits)

Or are you deploying a non-Rails application?

[shell362]

I think Kamal is expected to be the deployment tool for any application, so it looks like that's not the case yet.

[motdotla]

indeed. agree. it didnt have this promise originally but certainly does today so my comment is out of date.

[motdotla]

incidentally you can use dotenvx to effectively get a similar experience. It uses encrypted .env files you could mount.

Here is a docker guide: https://dotenvx.com/docs/platforms/docker

[JohnSmall]

If you use doctenvx you still have to pass a decryption key in. And with the present version of Kamal you can't do that in the build stage. You can pass secrets into the app when it's run on the server, but not into the build. Which causes problems when you get to bin/rails assets:precompile .

Can we modify Kamal to use BuildKit's secret mounting.

[torkelrogstad]

I'm looking into deploying services with Kamal, and I think it looks very promising. However, being forced to expose secrets as environment variables is disappointing, as that is very far from optimal security wise. I'm not working with Rails applications, and was hoping that Kamal would be usable also beyond the Rails ecosystem.