Support mounting kubernetes secrets

[alexstaeding]

I am using the velocity image type which requires a file named forwarding.secret in the server root. I tried mounting this file via a Kubernetes secret like this:

containers:
  - name: minecraft-proxy
    image: itzg/bungeecord:java17
    ports:
      - containerPort: 25577
    volumeMounts:
      - name: minecraft-proxy-volume
        mountPath: /server/logs
        subPath: logs
      - name: minecraft-proxy-volume
        mountPath: /server/plugins
        subPath: plugins
      - name: minecraft-proxy-volume
        mountPath: /server/velocity.toml
        subPath: velocity.toml
      - name: secret-volume # <--- here
        mountPath: /server/forwarding.secret
        subPath: secret-value
    env:
      - name: TYPE
        value: "VELOCITY"
volumes:
  - name: minecraft-proxy-volume
    persistentVolumeClaim:
      claimName: minecraft-proxy-pvc
  - name: secret-volume
    secret:
      secretName: minecraft-proxy-secret

...but the container hangs with this output:

Defaulted container "minecraft-proxy" out of: minecraft-proxy, init-velocity (init)
[init] Resolving type given VELOCITY
[init] Downloading https://papermc.io/api/v2/projects/velocity/versions/3.2.0-SNAPSHOT/builds/260/downloads/velocity-3.2.0-SNAPSHOT-260.jar
[mc-image-helper] 19:00:36.213 INFO  : Downloaded /server/velocity-3.2.0-SNAPSHOT-260.jar
chown: changing ownership of '/server/forwarding.secret': Read-only file system

If I instead mount /server/forwarding.secret via the minecraft-proxy-volume, the server starts without a problem.

[itzg]

I'll need to look at why it's even trying to do a chown at that point. Feel free to investigate and PR if you get to it before me.

[alexstaeding]

I had a look at the Dockerfile, I'm pretty sure this command is causing the problem:

https://github.com/itzg/docker-bungeecord/blob/04df9fedbe3c23bfa9597ce525e465049e7b7099/Dockerfile#L18-L19

Setting the home directory to /server will cause a chown on the whole directory which reasonably fails with read-only files.

And this is of course a bit of a problem because setting ownership of those files is necessary to start the server...

[alexstaeding]

I see two possible solutions:

1. Leave the image as-is. Modify the persisted velocity.toml to point to a forwarding.secret mounted outside of the /server directory. This is unclean as it requires some manual editing of the velocity configuration itself before the container can cleanly start.
2. Do not make /sever the home directory of the bungecoord user. I would need to investigate which files actually need to be owned/writable by velocity and only chown/chmod those.

[itzg]

Dockerfile commands are only executed during build time, so I'm thinking there's a call in the startup script that is running into trouble.

[celestecaprine]

Have you tried putting the forwarding.secret mount in /config? Files in there get copied to the /server directory when the container starts up.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please add a comment describing the reason to keep this issue open.

[itzg]

@alexstaeding looking again at this (to keep the bots away), your option 1 is what I would actually prefer. I'm wondering why velocity is looking to /server for the file in the first place? Is it simply because that's the working directory of the image?

[alexstaeding]

Have you tried putting the forwarding.secret mount in /config? Files in there get copied to the /server directory when the container starts up.

Okay... I'm not sure why I didn't try this before, but it seems to work when mounting in /config. I'd say that resolves this issue.