Public/Private view

[jangrewe]

Describe the feature request

Hi, after discovering that Uptime Kuma doesn't support config files (WTF?), i luckily came across Gatus and knew immediately that this is what i actually want to run! <3

The one feature i'd really like to see would be being able to keep the status page publicly accessible, while also enabling authentication and providing an extended list of checks that are not publicly visible - e.g. anonymous users see only website endpoints, authenticated users see services, private websites, DNS, etc.
This could be done by adding another field to the config dict for an endpoint, e.g. public: False.

Why do you personally want this feature to be implemented?

I'm (obviously) self-hosting a metric shit ton of stuff and want to monitor everything (with the config generated automagically by Ansible from a metadata file for each service role), but i also don't want everyone to see everything i host. I could just run 2 instances of Gatus with separate config files, but that's not the "nice" solution. ;-)

How long have you been using this project?

1 hour

Additional information

No response

[TwiN]

Good idea - enabling authentication via security.basic or security.oidc could be tweaked so that:

• If all endpoints are private, use the current login behavior
• If some endpoints are private, but not all, show a login button somewhere on the dashboard
• If no endpoints are marked as private, use the current login behavior (for backward compatibility)

---

Unrelated, but I'd like to thank you for creating a feature request despite having only used Gatus for an hour :)

[jangrewe]

Yes, you summarized it exactly how i would love to see it! 😃
By now i'v been using Gatus for >2 weeks already, and there are some other minor feature requests mentioned in the "introduction" discussion (especially a toggle "show only unhealthy/healthy/all), but this feature to make a Gatus instance semi-private is my biggest wishlist item. 😍

[ivan-zaitsev]

@TwiN It would be good to have a feature to restrict specific group based on security. For example in OIDC there is a claim called groups which can be used for this feature. For basic security I suppose it can be resolved by creating multiple credentials which would have different groups assigned. Currently it is only possible to achieve this by deploying different instances of application per group.

---

For example:

Basic:

security:
  basic:
    users:
      - username: "gatus-username"
        password: "..."
        groups: ["gatus-group1", "gatus-group2"]

---

OIDC:

Sometimes token group can be represented as UUID or as resource URI, to make it more flexible group-mappings can be added to map token groups to Gatus groups.

security:
  oidc:
    groups-claim: "groups"
    groups-mappings:
      gatus-group1: token-group-1
      gatus-group2: token-group-2

---

Also either not included groups should be by default public, or it is even more secure to make all groups by default secure and create different section for non-authenticated users.

Public:

security:
  public:
    groups: ["gatus-group3"]

[xeruf]

I would love that as well, also a recent convert from Kuma :)

[tigattack]

This would be super useful. I also switched over from Uptime Kuma a couple of days ago, and I'm loving Gatus so far, but this would be a really nice addition!

[SkilledAlpaca]

One thing that Uptime Kuma did that I greatly miss, is the dashboards by url.

I could host internal.domain.com and external.domain.com each with their own endpoints.

[TwiN]

Totally open to this feature if somebody wants to give it a try.

I think having a per-endpoint configuration that allows marking specific endpoints as private/requiring authentication would be the way to go.

[loispostula]

in #1328 I've started giving a shot to this feature.

My idea was:

1. Add a parameter on endpoint, external_endpoint and suites to mark them as Public.
2. Tweak the security config to allow authentication to be set either at global level, or endpoint level (Should probably be called resource Level)
3. If the auth is at endpoint level, then the auth middlewares doesn't returns 401 but the response from the protected API are filtered.
4. Finally the UI should be adapted to have a login form to display the base ui if not authenticated