Propagation
Introduction
Speaking about propagation, we mean distribution of changes made in system to the particular destinations.
For example, simple action as adding a new VO member by VO manager has large consequences as creating /home directories, setting an access rights, adding line in passwd... etc. for the user at all VO's resources
Propagation does not only transport completely new state to destinations, but also runs pre-installed scripts on machines to make all necessary changes (configure services, create directories, set access rights...).
Propagation of new state has several significant advantages. Sometimes happened situation when destination must be reinstalled or new hardware is added into infrastructure. Its inner state is lost or empty, but only one update from Perun, gives it new up-to-date state.
Consequently, destinations keep the state until the new one is send by Perun. Destination can run on their own also when Perun system would not work.
Package of open source bash scripts to run on destinations is delivered with Perun installation. There are fully functional and ready to run, but when administrator wants, he could edit or customize them, or even more, replace with his own scripts. He has the control about what Perun does in destination fully in his hand.
Propagation workflow
Considering action when VO manager has added a new member into his VO, information about this change goes to Audit log. This log is read by Engine, so a change influencing resources is detected and processed.
First, engine calls GEN scripts. These GEN scripts generate complete new state of the destination including the current change (e.g. new line in passwd).
As a second step, engine calls SEND script. This script takes new state generated in first step by GEN script and sends it to destination via SSH (most common way) or any other channel (for example email or jabber ).
As a third step, SEND script triggers SLAVE script "perun" stored in destination. Perun usually uses root access to run SLAVE script in a destination, but often Perun simply does not need it. It can run as any user, but the user has to have a proper rights to run all associated SLAVE scripts.
SLAVE script identifies type of service and checks versions of service script. This controll is important due to new versions of SLAVE scripts. When version of service script matches with version of SLAVE script, then, predefined SLAVE script configuring particular service in destination is run.
Sometimes destinations have specific requirements (e.g. settings of home directories, paths to scripts etc.). To fullfil this requirements without change of slave script, pre and post scripts are used. They can complement functionality of slave scripts.
When slave script starts, it searches for pre_ script in the service directory and runs it before its own functionality. The same process is after slave script execution, the post_ scripts are run. Use of script is optional, but it can be utilized by administrator, who want to add a new functionality to our Perun scripts. Pre and post scripts simply bring higher level of customization.
After finishing the whole process, as a response SLAVE script returns status to SEND script, which report it back to Perun system.
All return codes obtained from destination are checked on regular basis (e.g. once per hour) and when error code has been occured, repropagation can be triggered.
Propagation and security
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.
