Best posts made by fiwand

Access tokens currently inherit the full set of permissions from their owners. We'd love to be able to limit the routes that can be accessed by an individual token.

Proposed solution

Since predefined scopes are difficult to get right, we propose to instead support a path-based allowlist for a token (as a multiline plain text) in the "Create API Token" modal, where each line specifies an allowlisted route, possibly with wildcards for individual segments. Example:

GET /api/v1/cloudron/graphs
GET /api/v1/notifications
GET /api/v1/notifications/*
GET /api/v1/apps/*/logs

Note: The inclusion of the base path and syntax for wildcards or patterns may need some further discussion.

Use cases

• Custom dashboards: We created a custom dashboard in Observable where we consume the apps and cloudron/graphs routes. This dashboard cannot currently be shared with users who have a lower access privilege as it would expose an admin-level token.
• CI/CD hardening: We are currently investigating how we can reduce the risk of privilege escalation in a CI/CD environment. An admin-level token is currently used to create and tear down staging apps, and to configure their aliases. Once Cloudron 6.4 has been released we might also assign operators this way. Restricting routes may offer some level of risk reduction should a user gain access to the token.

Alternatives

We might be able to set up an HTTP proxy as API middleman. The proxy would be configured with an admin-level token, but would manage an internal set of tokens with their own set of retrictions.

App graphs are currently averaged over a timespan of 6 hours per datapoint (or 5 minutes for the past 24 hours), which can give a misleading picture of the app's actual memory consumption. For example, you're unlikely to see a spike that would force the app to restart.

We can partially solve this problem by also including target data for min and max values in the graph.

To give a concrete example, here is a Vega-Lite plot of the raw datapoints (memory and swap):

We see a spike right at the beginning, but looking at the Cloudron graph this spike is absent:

Here is a Chart.js recreation of the Cloudron graph, but with added targets for min and max. Also, tension has been set to 0 to not give the false impression that the data resolution would be higher than it actually is:

The exact representation would still have to be figured out, but hopefully this example can serve as a basis for further discussion.

A few more observations:

• The number of queried datapoints varies greatly, from 288 for the past 24 hours down to 28 for the past 7 days. I'd recommend to define a fixed number of datapoints and calculate the interval based on the selected period. If we go with 144 datapoints, we end up with the following intervals:
  • 12 hours: 5min (currently 5min)
  • 24 hours: 10min (currently 5min)
  • 7 days: 70min (currently 6h)
  • 30 days: 5h (currently 6h)
• Gaps are currently filled with preceding values (or 0 for the missing values at the beginning). I'd argue that any null values should be passed to Chart.js and shown as gaps in the chart.
• The timestamps in the returned graphite data are currently dropped, and instead the offsets are recalculated. I'm not sure why this has been done, and would recommend to just convert the timestamps that are already associated with the data. Afaik these are identical for all targets.

(Please correct me if any of these are wrong.)

Kuma only supports a single admin user account, but provides two features for team/public access:

• the ability to create a public dashboard
• the option to completely disable Kuma's authentication

We'd like to use the public dashboard feature as an internal dashboard, but cannot currently do so because our Cloudron instance is public-facing.

Is there a way to add an optional HTTP authentication layer to the Kuma Cloudron app? A single set of credentials would be perfectly fine for our use case, but we're also OK if other authentication requirements, like being a cloudron user, would make an integration easier or more versatile. We also don't need the authentication to only target specific paths.

Thanks!

@girish said in Default Open Registration - A Security Problem:

there used to be a way to add an admin user programmatically but now we have a wizard (which I guess they want to collect info on the setup).

I guess you're referring to https://docs.rocket.chat/quick-start/creating-the-first-administrator? Does this approach no longer work?

Edit: It also looks like an initial user can be provided as JSON via the INITIAL_USER env var: https://github.com/RocketChat/Rocket.Chat/blob/ba15ba725a09581c2aba9b7eb539e255a7908697/server/startup/initialData.js#L121