As you already know, service (for example ssh, ftp, web server) is assigned to destination in system Perun by Facility manager. Destination is a target, where configuration of service is propagated. There are several types of destination, for example email (new configuration is send to the given email address), but in your case we use type HOST (new configuration is send directly to the machine). When destination accepts the configuration, pre-installed scripts are run on destination to make all necessary changes. For better insight, see figure Propagation workflow.
Perun does not send only configuration from facility to machine, but this configuration also contains data about "destination" (hostname of machine receiving configuration from Perun) and "facility" (facility for which configuration is built). These attributes are further important for machine to distinguish whether accept configuration or not.
Facility manager (for example manager of facility carach.ics.muni.cz serving as cloud frontend) can assign as destination machine's name (for example carach1.ics.muni.cz) or alias (for example cloud-frontend.ics.muni.cz) or its IP address in Perun. The last two possibilities (alias, IP) could cause problems because manager can insert an alias or IP out of scope of his rights.
As example, evil facility manager of skirit.ics.muni.cz can assign as destination alias cloud-frontend.ics.muni.cz as a destination for some service, despite the fact that he is not manager of machine with alias cloud-frontend.ics.muni.cz. The machine is registered in the Perun, but its alias is not present.
Because evil facility manager assigned as destination alias, which is not in the system, inner control mechanism can not avert this attempt to fraud behavior. The inner control mechanism will be further described later on in the text.
Since evil facility manager saved this settings, machine carach.ics.muni.cz. with alias cloud-frontend.ics.muni.cz will receive configuration from facility skirit.ics.muni.cz which is under full control of the evil manager.
Perun has inner system of control whether facility manager has right to assign service to destination. It covers situation when assigned value is stored in Perun database.
Inner control mechanism consists of following rules: The facility manager can add name of new destination (or host) to service if and only if
There is no host and no destination with the name in the system.
There is a destination or host connected with the facility, where the manager is facility manager.
Inner control mechanism does not cover situation when facility manager assign value of destination out of Perun coverage (for example new alias of destination). To avoid potentially fraudulent behavior, destination accepts configuration where value of attribute "destination" equals to the result of command `hostname -f` as default. To change default settings, destination (host) manager must fill variables DNS_ALIAS_WHITELIST or FACILITY_WHITELIST with values (IPs, aliases, destination's name). These values are then compared with attributes "destination" and "facility" delivered with new configuration.
These variables are set in: /opt/perun/bin/perun or in /etc/perunv3.conf:
# accept configuration only if it was send to one of these hostnames
# prevent someone to configure perun to send malicious configuration via dns alias or ip address
DNS_ALIAS_WHITELIST=( `hostname -f` )
FACILITY_WHITELIST=() # from which facilities this host accepts configuration,
# insert facility name as is in Perun.
DNS_ALIAS_WHITELIST accepts both IP addresses and aliases (only one value is enough for one machine), values are separated by space.
For example DNS_ALIAS_WHITELIST = (86.49.81.84 cloud-frontend.ics.muni.cz) FACILITY_WHITELIST accepts facility names (as are named in Perun), values are separated by space. For example FACILITY_WHITELIST=(carach.ics.muni.cz)
To allow service propagation, both whitelists are checked and match in only one whitelist is enough to accept the configuration.
