-
-
Notifications
You must be signed in to change notification settings - Fork 312
Fix: adding "APP_TRUSTED_PROXIES" variable #569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
LoveSkylark
wants to merge
10
commits into
librenms:master
Choose a base branch
from
LoveSkylark:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+2
−0
Open
Changes from 7 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
1b1bc34
Fixing trusted proxies
LoveSkylark 16d081c
making docker default only
LoveSkylark a7cc10b
Merge branch 'master' into master
LoveSkylark 253a26e
Remove APP_TRUSTED_PROXIES
LoveSkylark 5a7d8e5
Remove APP_TRUSTED_PROXIES setting
LoveSkylark 792e200
Remove APP_TRUSTED_PROXIES from environment file
LoveSkylark f34e4ad
Clarify APP_TRUSTED_PROXIES description in README
LoveSkylark 0b3f364
removing default values from APP_TRUSTED_PROXIES
LoveSkylark 7d409f6
Remove unneeded changes
murrant 9cf6d54
Update APP_TRUSTED_PROXIES description in README
murrant File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do we think about this as a default? I'm unsure since it differs from upstream. But at least you document it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your are right this range is wrong, back in the old days I used to do exactly this: everything landed on the default bridge, so whitelisting 172.17.0.0/16 gave you a simple, ready-to-go path between your reverse proxy and any other container you spun up on the host. That's was the intent here.
Looking at the example in this repo, we're not even separating the reverse proxy from the LibreNMS server (Traefik and LibreNMS share one compose network), which will be 172.18.0.0/16 most of the time on a basic host. If we want a default to cover more than just the example scenario, it should be 172.16.0.0/12, which covers all the /16 networks Docker hands out on a host of this size.
That said, I don't have a strong stake in how this lands, I won't be using it myself (I run this in Kubernetes), I was just trying to make this easier for the most basic Docker deployments.
I appreciate your dedication to LibreNMS. Feel free to make whatever adjustments you want to this PR — or close it if that's easier. I don't plan to spend more time on it myself.
This wouldn't be the first fix I've submitted that stalled out in rounds of small tweaks. Honestly, I don't think senior contributors like you should have to wait on a drive-by contributor like me for changes you already know should be in there — just make them directly. I'm fine with whatever the result looks like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I just noticed.
REAL_IP_FROMIs this a duplicate? does it clash?Also,
APP_TRUSTED_PROXIESmeans trust the headers passed to me (not real ip specifcally, but it includes that)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im baffled,
A change was implement the breaks docker deployment with any kind of proxy in front, and we are tunnel visioning on what is the best default setting instead of implementing the fix.
Strip default away set the description to what ever you like, just get the fix through then we can start tweaking that the bets setting is and how it is best described.
This is like not fixing a broken window because you cant decide what color curtains will go with the new window :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You do realize nothing is broken right?
Its a setting you change... Set an env var, edit the example compose, do what you need. The reason it changed is because it allowed man in the middle attacks...
I get your frustration with getting the change through, but its better to stay on the side of safely failing on boot rather than exposing company data because someone forgot to change a default setting
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better analogy, it is like leaving the window open because the window is broken and you don't want people to get in through the broken window. Also, change the window to a door and add a lock... ok I'm lost now.
Just like this PR. I don't really use the docker in the real world which is why I ask so many questions. I don't want to break user's installs or expose their data. We are trying to walk a fine line. Changing defaults has much more wide reaching impact and we have to be careful.
Not having APP_TRUSTED_PROXIES in the docs was a major oversight and I would have merged that almost right away.
Again, I have no idea what is going on with the docker image and a lot of people come in with incorrect assumptions (me included) and have different environments. We can get silly things like duplicate variables. Which is very hard to undo.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Yoyasp have you tested this?
It's true that
APP_TRUSTED_PROXIESgets passed into the containe, you can see it withenvfrom a shell inside. The problem is that PHP-FPM strips environment variables from its worker processes as a security measure (clear_env = yesby default), so the web UI never sees the value even though the container has it.This can be bypassed with the
CLEAR_ENVvariable the image exposes, but that disables the scrubbing entirely, exposing every container variable, includingDB_PASSWORD, to all web-facing PHP code. Arguably a broader security tradeoff than just settingAPP_TRUSTED_PROXIES="*", but it's what I'm currently running to keep my deployments working.Alternatively, PHP-FPM supports whitelisting individual variables through the security filter by adding
env[APP_TRUSTED_PROXIES] = $APP_TRUSTED_PROXIESto the pool config (www.conf). But that config is regenerated on container start, and its path changes with PHP version bumps and third-party modifications, so the customization can silently get lost.The original image sidesteps this for its core settings by writing them into Laravel's .env at container start via the deployment script (rootfs/etc/cont-init.d/03-config.sh).
This is where my pull request went off the rails. My first thought was to simply add
APP_TRUSTED_PROXIES=${APP_TRUSTED_PROXIES}into the .env file . But then anyone not setting the variable would getAPP_TRUSTED_PROXIES=and an empty value there overrides LibreNMS's built-in default rather than falling back to it. My workaround was to ship default values covering the internal IP ranges Docker and Kubernetes use, unreachable from outside the cluster, analogous to trusting127.0.0.1on a bare-metal install. That sidetracked the whole PR into a discussion about which internal ranges belong in the defaults.So in my latest commit I've taken
APP_TRUSTED_PROXIESout of the heredoc entirely and instead append it to.envonly when the variable is actually set. The script already uses this exact pattern forRRDCACHED_SERVER, so it follows the file's existing convention rather than inventing a new one.