starred/uptime-kuma

Fork 0

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

Support for secret variables #3405

New issue

Open

opened 2026-02-28 03:28:20 -05:00 by deekerman · 14 comments

deekerman commented

2026-02-28 03:28:20 -05:00

Owner

Originally created by @nickfla1 on GitHub (Jun 11, 2024).

I was unable to find any related issue.

🏷️ Feature Request Type

New monitor, Change to existing monitor

🔖 Feature description

It should be possible to manage secret keys/values and use them inside URLs, headers and Authentication methods without showing them in the dashboard as plain text.

✔️ Solution

We should be able to manage secrets via a dedicated settings section. I don't believe it would be necessary to allow for a full CRUD interface, Create and Delete should be enough.

Each key should have an unique name which can be referenced inside URLs and Headers:

https://myapi.example.com/foobar?apikey={{ my_key_name }}

{
  "Authentication": "Bearer {{ my_key_name }}"
}

https://myapi.example.com/foobar?apikey={{ secrets.my_key_name }}

{
  "Authentication": "Bearer {{ secrets.my_key_name }}"
}

❓ Alternatives

No response

📝 Additional Context

Showing plain text keys or secrets is always a security concern, sometimes even in the same organization you don't want to be so open about who can easily read those values.

Originally created by @nickfla1 on GitHub (Jun 11, 2024). ### 📑 I have found these related issues/pull requests I was unable to find any related issue. ### 🏷️ Feature Request Type New monitor, Change to existing monitor ### 🔖 Feature description It should be possible to manage secret keys/values and use them inside URLs, headers and Authentication methods without showing them in the dashboard as plain text. ### ✔️ Solution We should be able to manage secrets via a dedicated settings section. I don't believe it would be necessary to allow for a full CRUD interface, Create and Delete should be enough. Each key should have an unique name which can be referenced inside URLs and Headers: ``` https://myapi.example.com/foobar?apikey={{ my_key_name }} ``` ```json { "Authentication": "Bearer {{ my_key_name }}" } ``` or ``` https://myapi.example.com/foobar?apikey={{ secrets.my_key_name }} ``` ```json { "Authentication": "Bearer {{ secrets.my_key_name }}" } ``` ### ❓ Alternatives _No response_ ### 📝 Additional Context Showing plain text keys or secrets is always a security concern, sometimes even in the same organization you don't want to be so open about who can easily read those values.

deekerman added the

feature-request

question

A:monitor

type:enhance-existing

labels

2026-02-28 03:28:20 -05:00

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@nickfla1 commented on GitHub (Jun 11, 2024):

If you second this proposal I am more than open to directly contribute to its implementation!

@nickfla1 commented on GitHub (Jun 11, 2024): If you second this proposal I am more than open to directly contribute to its implementation!

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 11, 2024):

Authentication: Bearer

We already handle this for the auth methods we currently support

Would accept a PR implementing Bearer Auth as an alternative to Basic Auth.

@CommanderStorm commented on GitHub (Jun 11, 2024): > Authentication: Bearer <details><summary>We already handle this for the auth methods we currently support</summary> <p> ![image](https://github.com/louislam/uptime-kuma/assets/26258709/236ad15a-753f-4fc1-a310-3681288c6fad) </p> </details> Would accept a PR implementing Bearer Auth as an alternative to Basic Auth.

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@nickfla1 commented on GitHub (Jun 11, 2024):

Authentication: Bearer

We already handle this for the auth methods we currently support
Would accept a PR implementing Bearer Auth as an alternative to Basic Auth.

I can work on that in the next few days

@nickfla1 commented on GitHub (Jun 11, 2024): > > Authentication: Bearer > > We already handle this for the auth methods we currently support > Would accept a PR implementing Bearer Auth as an alternative to Basic Auth. I can work on that in the next few days

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 11, 2024):

About the url templating, I am not entirely sold. Don't think this solves your issue.
I mean, if you want to protect the secrets from other people you share the password with.. They could simply change the url to be https://webhook.site and extract the secret via that.

@CommanderStorm commented on GitHub (Jun 11, 2024): About the url templating, I am not entirely sold. Don't think this solves your issue. I mean, if you want to protect the secrets from other people you share the password with.. They could simply change the url to be https://webhook.site and extract the secret via that.

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@nickfla1 commented on GitHub (Jun 12, 2024):

About the url templating, I am not entirely sold. Don't think this solves your issue. I mean, if you want to protect the secrets from other people you share the password with.. They could simply change the url to be https://webhook.site and extract the secret via that.

I'm not sure I'm following, wouldn't the template be compiled when the Kuma is invoking my configured monitor? How could anyone intercept that?

I admin that I'm yet to figure out how I'd implement it within Kuma

Would accept a PR implementing Bearer Auth as an alternative to Basic Auth.

Also, reconsidering, this wouldn't work for my use-case as we use custom headers as API keys

@nickfla1 commented on GitHub (Jun 12, 2024): > About the url templating, I am not entirely sold. Don't think this solves your issue. I mean, if you want to protect the secrets from other people you share the password with.. They could simply change the url to be https://webhook.site and extract the secret via that. I'm not sure I'm following, wouldn't the template be compiled when the Kuma is invoking my configured monitor? How could anyone intercept that? I admin that I'm yet to figure out how I'd implement it within Kuma > Would accept a PR implementing Bearer Auth as an alternative to Basic Auth. Also, reconsidering, this wouldn't work for my use-case as we use custom headers as API keys

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 12, 2024):

Let's assume you first have a monitor pointing to https://example.com?key={{secret.key}} then the attacker with your admin credentials changes it to webhook.site/...?key={{secret.key}}.

Now the attacker has your secret, the same was as if he had read it in the UI.

@CommanderStorm commented on GitHub (Jun 12, 2024): Let's assume you first have a monitor pointing to `https://example.com?key={{secret.key}}` then the attacker with your admin credentials changes it to `webhook.site/...?key={{secret.key}}`. Now the attacker has your secret, the same was as if he had read it in the UI.

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@nickfla1 commented on GitHub (Jun 12, 2024):

Let's assume you first have a monitor pointing to https://example.com?key={{secret.key}} then the attacker with your admin credentials changes it to webhook.site/...?key={{secret.key}}.

Now the attacker has your secret, the same was as if he had read it in the UI.

Ah now I get it! Yes of course that could be an attack vector, thought if they have admin access that's not a lot we can do anyway.

To be more clear on our use case, we'd like read only users to not see some api keys in headers and query strings that now have to be set as plain text, it wouldn't solve any security issue in case of compromised admin access.

I think it might be useful to other Kuma's users as well

@nickfla1 commented on GitHub (Jun 12, 2024): > Let's assume you first have a monitor pointing to `https://example.com?key={{secret.key}}` then the attacker with your admin credentials changes it to `webhook.site/...?key={{secret.key}}`. > > Now the attacker has your secret, the same was as if he had read it in the UI. Ah now I get it! Yes of course that could be an attack vector, thought if they have admin access that's not a lot we can do anyway. To be more clear on our use case, we'd like read only users to not see some api keys in headers and query strings that now have to be set as plain text, it wouldn't solve any security issue in case of compromised admin access. I think it might be useful to other Kuma's users as well

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 12, 2024):

Readonly users is tracked in https://github.com/louislam/uptime-kuma/issues/1322 and at the moment quite gridlocked.

If you want to help said feature along, you can review https://github.com/louislam/uptime-kuma/pull/3571 or test said PR via this https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests method

@CommanderStorm commented on GitHub (Jun 12, 2024): Readonly users is tracked in https://github.com/louislam/uptime-kuma/issues/1322 and at the moment quite gridlocked. If you want to help said feature along, you can review https://github.com/louislam/uptime-kuma/pull/3571 or test said PR via this https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests method

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@nickfla1 commented on GitHub (Jun 13, 2024):

Even though they're in progress, do you think read-only users will be able to see URLs, request bodies and headers clearly?
If so I think my question still applies!

I'll probably work on the "Bearer" authorization PR anyway as I think it will improve the project, even though we don't use that authentication mechanism

@nickfla1 commented on GitHub (Jun 13, 2024): Even though they're in progress, do you think read-only users will be able to see URLs, request bodies and headers clearly? If so I think my question still applies! I'll probably work on the "Bearer" authorization PR anyway as I think it will improve the project, even though we don't use that authentication mechanism

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 13, 2024):

How fleshed out the permission system will be has not been defined.
Fleshing it out does not really make sense spending maintainer time on unless we have #3571 reviewed and tested.

@CommanderStorm commented on GitHub (Jun 13, 2024): How fleshed out the permission system will be has not been defined. Fleshing it out does not really make sense spending maintainer time on unless we have #3571 reviewed and tested.

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@ArthurQQII commented on GitHub (Jan 16, 2025):

Can we encrypt the secrets so they are never readable once saved, similar to GitHub secrets? The only way to retrieve the value would be to reset it. The encryption would be handled using a private application key, which should remain hidden inside the container through an environment variable or a similar method.

Regarding concerns about admin credentials being compromised by an attacker, this is a challenge common to all security scenarios. It's crucial to ensure the encryption key is stored securely.

Additionally, secrets should ideally be organized into different sets for various purposes. When a specific monitor needs access to secrets, it should only retrieve the relevant set, not the entire collection. This approach adds another layer of protection against potential attacks.

Here’s an additional thought (feel free to ignore if it's not relevant):
Integration with cloud-based secret management solutions could enhance usability. For example, AWS Secrets Manager, Kubernetes Secrets, etc., could be leveraged. Personally, I use Kuma in my EKS cluster. Centralizing secret management would simplify workflows significantly.

If anyone agrees with this idea or would like similar features, please give this comment a thumbs up. I’ll then start working on this and create a PR.

Thank you for taking the time to read this!

@ArthurQQII commented on GitHub (Jan 16, 2025): Can we encrypt the secrets so they are never readable once saved, similar to GitHub secrets? The only way to retrieve the value would be to reset it. The encryption would be handled using a private application key, which should remain hidden inside the container through an environment variable or a similar method. Regarding concerns about admin credentials being compromised by an attacker, this is a challenge common to all security scenarios. It's crucial to ensure the encryption key is stored securely. Additionally, secrets should ideally be organized into different sets for various purposes. When a specific monitor needs access to secrets, it should only retrieve the relevant set, not the entire collection. This approach adds another layer of protection against potential attacks. Here’s an additional thought (feel free to ignore if it's not relevant): Integration with cloud-based secret management solutions could enhance usability. For example, AWS Secrets Manager, Kubernetes Secrets, etc., could be leveraged. Personally, I use Kuma in my EKS cluster. Centralizing secret management would simplify workflows significantly. If anyone agrees with this idea or would like similar features, please give this comment a thumbs up. I’ll then start working on this and create a PR. Thank you for taking the time to read this!

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@martnaum commented on GitHub (Nov 26, 2025):

sometimes even in the same organization you don't want to be so open about who can easily read those values

Absouletly. I am running into that exact issue within the PostgreSQL monitor in Kuma. After the creation Kuma shows the connection string in plain text within the monitor configuration page which limits the usability on our end.

@martnaum commented on GitHub (Nov 26, 2025): > sometimes even in the same organization you don't want to be so open about who can easily read those values Absouletly. I am running into that exact issue within the PostgreSQL monitor in Kuma. After the creation Kuma shows the connection string in plain text within the monitor configuration page which limits the usability on our end.

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@nneul commented on GitHub (Dec 6, 2025):

I would encourage this to be done as "parameters" that could optionally be considered "sensitive" - not just "secrets".

The parameter could potentially have a "provider" - example would be callout to aws parameter store or secret manager if you were hosting on an environment like that. In my case, I'm more interested in just factoring them out of the individual conifgs into a clearly dedicated section of the UI for storing those central parameters --- and not having them duplicated - such as if I have 40 different monitors using the same credential.

I'd also like to use the same mechanism for factoring out some comment configuration strings. Certainly the authentication component would be the first usage, but being able to use for any factored out parameters would be similarly useful.

@nneul commented on GitHub (Dec 6, 2025): I would encourage this to be done as "parameters" that could optionally be considered "sensitive" - not just "secrets". The parameter could potentially have a "provider" - example would be callout to aws parameter store or secret manager if you were hosting on an environment like that. In my case, I'm more interested in just factoring them out of the individual conifgs into a clearly dedicated section of the UI for storing those central parameters --- and not having them duplicated - such as if I have 40 different monitors using the same credential. I'd also like to use the same mechanism for factoring out some comment configuration strings. Certainly the authentication component would be the first usage, but being able to use for any factored out parameters would be similarly useful.

deekerman commented

2026-02-28 03:28:25 -05:00

Author

Owner

@ScottCUSA commented on GitHub (Feb 10, 2026):

There was another issue opened which seemed more similar to my request but it was closed referring to this one, so I am going to post my request here.

What I would like to see added to Uptime Kuma is essentially a vault, or said another way, an encrypted-at-rest key/value store.

When creating a monitor, you can reference values from the vault, using the key, and Uptime Kuma will replace the key with the value from the vault when performing requests. This is something that is available in many API clients, Postman, Insomnia, Hoppscotch, etc.

The purpose of such a vault, is so when credentials change, I only need to edit the values in the vault.
As things stand currently, I would have to manually edit every request that uses the credentials.

@ScottCUSA commented on GitHub (Feb 10, 2026): There was another issue opened which seemed more similar to my request but it was closed referring to this one, so I am going to post my request here. What I would like to see added to Uptime Kuma is essentially a vault, or said another way, an encrypted-at-rest key/value store. When creating a monitor, you can reference values from the vault, using the key, and Uptime Kuma will replace the key with the value from the vault when performing requests. This is something that is available in many API clients, Postman, Insomnia, Hoppscotch, etc. The purpose of such a vault, is so when credentials change, I only need to edit the values in the vault. As things stand currently, I would have to manually edit every request that uses the credentials.