You are right thinking that using a large secret salt, such as a 256 bits value generated randomly (with a good CPRNG) should be fine.
Notice that we usually say that a salt can be known from the attack, which is not the case in your design, so you are not using a salt, but a key. Keyed-hash function are a thing (see BLAKE2, for example), but you can generally construct a keyed-hash function out of any hash function by simply hashing the concatenation of your key and your message with the said hash function.
In this latter case, which correspond to your design, the preimage resistance of the hash function would prevent the attacker from finding the "salted/keyed Resource ID" without knowing the key.
Using more than one key, like for example, one for each resource, would simply strengthen the system against potential leaks that might occur. Since then, if a key leaks, the rest of the non-leaked keys would still prevent an attacker from finding the image of a given Resource ID (or finding the preimage of a given hash by bruteforcing the possible Resource IDs, if those are known/in a small range).
Notice that the system you mention:
a system that takes that ID as an input parameter and produces a consistent output for a given resource
is somehow similar to a pseudo-random generator, where the key would be the resource ID. Using a keyed-hash function as you propose (as long as the key has enough entropy) is a way to construct such PRG, but there are some hiccups if you let the adversary possibly control your entropy pool... I'm looking for example at the "Hash_DRBG"...
Now another way around your problem, since you've got a key already, might be to simply encrypt the resource ID with a symmetric (AES, e.g.) and that key you called "salt"... (As long as that key is generated with a good entropy, using a CPRGN, you're safe.)
Plus you'd get the two-wayness you wanted, as you could simply decrypt the resulting value using the key to obtain the initial resource ID out of it.