[autobrr] Add autobrr chart

[funkypenguin]

Description of the change

Hey guys! Love your work!

Here's a PR to add a chart for "autobrr" (https://github.com/autobrr/autobrr) - I hope I've done it right!

Benefits

• New chart, happy users

Possible drawbacks

• None

Applicable issues

• fixes #

Additional information

Checklist

• [X] Title of the PR starts with chart name (e.g. [home-assistant])
• [X] Chart version bumped in Chart.yaml according to semver.
• [X] Chart artifacthub.io/changes changelog annotation has been updated in Chart.yaml. See Artifact Hub documentation for more info.
• [X] Variables have been documented in the values.yaml file.

[onedr0p]

@all-contributors please add @funkypenguin for code

[allcontributors[bot]]

@onedr0p

I've put up a pull request to add @funkypenguin! :tada:

[brettpetch]

Hey @onedr0p — it might be worth looking at this PR again. The app in question has a secret key that should be rotated across pods, I’m not seeing it being changed in the charts.

[onedr0p]

Huh? Sorry I'm not at all familiar with this application.

[brettpetch]

Huh? Sorry I'm not at all familiar with this application.

There’s a session key that needs to be generated for the config to be considered complete. I’ve provided a review with a potential solution, although I’ve never written a helm chart before.

According to the documentation from the autobrr dev team,

sessionSecret: Used for session cookies. Change to something more random like a UUID.

https://autobrr.com/docs/getting-started/installation

Here’s a working installer that’s made for on the metal installs, but the same technique should be able to be transferred.

https://github.com/swizzin/swizzin/blob/master/scripts/install/autobrr.sh#L52

[brettpetch]

The application also has optional postgres support, but I’m unsure if this needs to be a separate chart or if it can be a switch people can flick— I’m not sure what the project structure is here.

[onedr0p]

@funkypenguin what do you think of these changes?

[funkypenguin]

The app description was a copy/paste oversight, I'll submit a PR to fix that :)

WRT the session secret, my feeling is that in this context, we're better served by keeping the helm chart simple, and avoiding auto-created config values. The chart user is free to alter the config their values.yaml, and set the session secret themselves, but doing it programmatically would be fiddly, and not worth it IMO.

If the config options could also be passed to the app via ENV vars (which override the config), then there's could be a case made for further automating the configuration.

[brettpetch]

Allowing users who have successfully authenticated on another instance with the same key could just login to this one using the same cookie... How is that a good solution to authentication? The session key should be generated for every pod as it pretty much allows unfettered access to the person's accounts, api keys, filters, download clients, and is a huge RCE vulnerability in itself if left unchecked.

For your implementation it may make sense, but at a broader scale of someone just wanting to spin up an instance of the application in a pod, it serves as a massive security hole if the application is not behind some kind of authentication.