All realms support the notion of trusted hosts. By default, if no user ID is specified, the currently logged-in system user ID is used. Authentication credentials (in realms that use them) are not required when a request originates from a trusted host and the requester does not provide a user ID (thereby defaulting to the current system username). Realms can override this behavior.
The trusted hosts mechanism should only be used on tightly controlled private operational networks. The integrity of the trusted host mechanism relies on the access control and auditing of the host operating system. The trusted hosts mechanism is not appropriate for public networks, or for general company-wide private networks, where it should be disabled.
You can specify a list of trusted hosts as part of the node's initial configuration, and you can later update the trusted host list with an epadmin command to a running node.
The node's host machine is always trusted by default, so you do not need to specify localhost, or 127.0.0.1 or ::1.
You can provide a comma-separated list of hosts in any of the following formats:
Simple host names
Fully qualified domain names
Partially qualified domain names
IPv4 single addresses
IPv6 single addresses
CIDR blocks of IPv4 addresses
CIDR blocks of IPv6 addresses
After the node is installed and running, you can use epadmin load configuration to load a new TrustedHosts configuration file. You can then deactivate the current configuration and activate the new one. See epadmin help configuration for assistance.
There can be only one active trusted host configuration per node, although there can be multiple independent TrustedHosts configuration files within the node.
Even when switched to an enterprise-level realm such as LDAP or OIDC that requires and manages credentials for each user, you can still require node connections to originate from a trusted host. This adds whitelist security on top of the realm's authentication security to further narrow the range of authorized users.