Trusted Hosts

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.

Caution

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.

Specify the node's initial trusted host list with a configuration file of type security with root object TrustedHosts.

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

Remember that parameter value strings in HOCON files that contain a period must be quoted. This includes domain name and IP address strings.

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.