Cloudflare Tunnel: Hide Cloudflare token from the process argument

[Eskander]

⚠️ Please verify that this feature request has NOT been suggested before.

• [X] I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

When I run uptime-kuma in a Docker container and set up Cloudflare tunnel, the token is exposed outside the container and any random process running on the host machine can get it in plaintext, for example with a simple ps -aux:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user       53614  0.6  0.8 745348 35936 ?        Sl   19:59   0:02 cloudflared tunnel --no-autoupdate run --token eyJhIjoiNmNmZDE0OWNjZT......

This defeats the purpose of mechanisms such as Docker secrets, Kubernetes Secrets etc.., and I suppose the Cloudflare token should be treated as sensitive data because it effectively controls what's hosted on the website.

So in this feature request, I suggest to consider a different method to pass the token to cloudflared.

✔️ Solution

Environment variables are currently the recommended best practice in Docker(?), so this could be used to invoke cloudflared: env TUNNEL_TOKEN=token_goes_here cloudflared tunnel run The token is no longer exposed in the process list:

$ ps -aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user      221537  0.7  0.9 745348 36484 pts/0    Sl+  20:33   0:02 cloudflared tunnel run

❓ Alternatives

Use a config file, it's apparently possible but I haven't looked into it. Or keep things as is, if the current situation does not present a problem?

📝 Additional Context

No response

[bmidgley]

A true Zero Trust philosophy would require this to be a high priority! It's over a year old!

[CommanderStorm]

@bmidgley If this is a priority to you, consider making the PR nessesary. Things in open source move because volunteers spawn to do the work...

Why I don't consider it high priority for my use case (=> won't work on this during my vacation):

In docker the container is isolated from the host, the host is not isolated from the container. So from the host, you can see the files, network connections, network interfaces, processes, etc, that are used inside the container. But from the container, you can only see what's in the container (barring any privilege escalation configured in the run command).

There are a number of mechanisms you can configure to isolate the other way too (namespaces, hidepid, ..)

[bmidgley]

@CommanderStorm I'm glad to see your response. It sounds like you are a volunteer. I believe Cloudflare the company should be making security a high priority and paying staff to work on these things in regular work hours. As a user of the system, I might just find another company that does similar work rather than fix this infrastructure. I love writing software, but I'm in the application and don't have time set aside to work in the security layers.

People who work in security are constantly trying to find ways to add layers of protection, monitoring, and validation in an endless arms race. It's not a satisfying story to say that container separation will protect us. It means only one privilege escalation is necessary to take advantage of this weakness.