"...there is no reason for the components of the app to depend on those things being global..."
BINGO! This is the anti-pattern part. Not that the data is globally required, but that your units are mutually dependable. This is why Interfaces and Dependency Injection are so popular now, because they facilitate the ability to make easily testable, singular units that allow for mocks / stubs etc.
To illustrate, what happens if your global requirement happens to also be external? Would you want to have to test your component with a live version of your global and external resource? No, you would want the ability to test (either as a single unit, or even the whole app), without requiring the database, messaging, web service, etc, to be up.
Sure, but for the most part, there is no reason for the components of the app to depend on those things being global (and a significant cost in brittleness for them to do so), so, in general, they should be passed to the objects that need them, even if they are globally consistent throughout the app.
Obviously, there are optimization reasons why you might need to avoid doing this in particular cases, but in general doing so up-front is going to be a premature optimization.