starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Cloudflare Tunnel: Hide Cloudflare token from the process argument #1992

New issue

Open

opened 2026-02-28 02:39:31 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 02:39:31 -05:00

Owner

Originally created by @Eskander on GitHub (Mar 11, 2023).

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

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

Originally created by @Eskander on GitHub (Mar 11, 2023). ### ⚠️ 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](https://docs.docker.com/engine/swarm/secrets/), [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) 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](https://github.com/cloudflare/cloudflared/issues/645#issuecomment-1136486550) 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_

deekerman added the

feature-request

A:deployment

security

labels

2026-02-28 02:39:31 -05:00

deekerman commented

2026-02-28 02:39:37 -05:00

Author

Owner

@bmidgley commented on GitHub (Sep 4, 2024):

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

@bmidgley commented on GitHub (Sep 4, 2024): A true Zero Trust philosophy would require this to be a high priority! It's over a year old!

deekerman commented

2026-02-28 02:39:37 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Sep 4, 2024):

@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, ..)

@CommanderStorm commented on GitHub (Sep 4, 2024): @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, ..)

deekerman commented

2026-02-28 02:39:37 -05:00

Author

Owner

@bmidgley commented on GitHub (Sep 4, 2024):

@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.

@bmidgley commented on GitHub (Sep 4, 2024): @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.