gLite-VOBOX
Functional description
The VO-box is a type of node where experiments can run specific agents and services to provide a reliable mechanism to accomplish various tasks. It is provided as an interim solution in order to allow experiments to provide their own services whenever the middleware still does not provide the required functionality. The access to the VO-box (or VO node) is restricted to the Software Group Manager (SGM) of the Virtual Organisation (VO).
Note that there is not a unique description about "the" gLite VO-box as each VO provides
their own requirements. At the time when the VO-box has been deployed, the VOs have
completed the "LCG VOBox Operations Recommendations and Questionnaire" which
describes, for instance, the requirements on the hardware (e.g., "any modern dual CPU
system would be sufficient"), the preferred operating system (Scientific Linux 3 usually), or
the requirements on the backup policy. The VO software running on the VO-box, and the
open ports, are described in the "VO-Box Security Recommendations and Questionnaire"
(VOBOX-SRQ).
Templates of the questionnaires have been provides by the Joint Security Policy Group.
See the VO-box WIKI for the templates and the current versions of the completed
questionnaires:
https://twiki.cern.ch/twiki/bin/view/LCG/VoBoxesInfo.
Released Version
http://glite.web.cern.ch/glite/packages/latestRelease.asp
Daemons running
- a GSISSH server (running by default on port 1975) which allows ssh connection authorized through X509 proxies and proxy delegation (/opt/globus/sbin/sshd -p 1975)
- a GRIS (registering to the site GIIS) which publishes the GSISSH service and port; (usually : /usr/sbin/slapd -f /opt/bdii/var/2171/bdii-slapd.conf -h ldap://localhost:2171 -u edguser)
- a Proxy Renewal Service (together with a user level tool) to ensure automatic refresh of user credentials; (/opt/lcg/sbin/vobox-renewd)
Init scripts and options (start|stop|restart|...)
- /etc/init.d/bdii
- /etc/init.d/<VO>-box-proxyrenewal
- /etc/init.d/dteam-box-proxyrenewal
- /etc/init.d/ops-box-proxyrenewal 1)
- /etc/init.d/gsisshd
- ... and possibly any more VO-box specific daemons provided by the VOs
Remarks:
1) If the VO-box is monitored by central SAM services.
Configuration files location with example or template
YAIM site-info.def
example file:
- /opt/glite/yaim/examples/siteinfo/site-info.def
Please check
https://twiki.cern.ch/twiki/bin/view/LCG/Site-info_configuration_variables#VOBOX for modifications.
Logfile locations (and management) and other useful
- /var/log/secure
- /var/log/vbox/
- /var/log/lcg-expiregridmapdir.log
- /var/log/fetch-crl-cron.log
- /var/log/edg-mkgridmap.log
- /opt/bdii/var/bdii.log
- /opt/bdii/var/bdii-fwd.log
There are maybe rather more logfiles depending on the VO daemons running on the VObox.
See the VOBOX-SRQ for details.
Open ports
- 2171 for GRIS (has to be open only for inbound connections from site BDII)
- 1975 for GSISSH
Possible unit test of the service
https://twiki.cern.ch/twiki/bin/view/LCG/SAMTests#VOBOX
The VO must document specific connectivity requirements, preferably via the VOBOXSRQ.
They should provide a full description of all required ports (inbound and outbound),
and the corresponding remote destinations.
VOs may request a specific port to be used by the VO daemons running on the VO-box,
but this will not guarantee actual assignment of the specific port requested. For operational
reasons, or in case the port has already been assigned to a different service, an alternate
port may be assigned. VO software must be able to handle such alternate assignments.
Where is service state held (and can it be rebuilt)
!!! INCOMPLETE !!!
The Question was not entirely understood, it should be rephrased.
Cron jobs
- bdii-proxy
- <VO>-box-proxyrenewal
- dteam-box-proxyrenewal
- ops-box-proxyrenewal 1)
- edg-mkgridmap 2)
- lcg-expiregridmapdir
- fetch-crl 2)
Remarks:
1) If the VO-box is monitored by central SAM services.
2) These cron jobs are not used if the site provides the appropriate files using a
centralized file distribution service like CFengine.
Security information
Access control Mechanism description (authentication & authorization)
Interactive logins are only permitted using GSISSH. Authentication is based on grid
certificates. Authorization is controlled by the gridmapfile.
VOs must provide a description of the access control mechanisms used by the VO specific
daemons running on the VO-box.
How to block/ban a user
An individual user can be blocked from interactive logins to the VO-box by removing the
DN from the grid-mapfile.
The other daemons running on the VO-box are under control of the respective VO.
Quoting from the VOBOX-SRQ:
"Preferably, the service SHOULD implement a blacklisting
capability for individual client subject names, to be configured by the site. If such a
mechanism is absent, the site will be required to disable the entire VO box in case of
incidents."
Network Usage
The VO-boxes are connected to the site fabric as well as to the world. Connectivity on the
VO box will generally be managed and contained according to site policies. Inbound
connectivity to privileged ports is prohibited. The VOs propose their requirements via the
VOBOX-SRQ.
Firewall configuration
The Software Grid Manager (SGM) of the VO can login to the VO-box using GSISSH
which is by default running on port 1975.
Other deamons running on the VO-box are described in the VOBOX-SRQ. It must also
provide the ports used for inbound and outbound connections, as well as the remote
destinations.
Security recommendations
The VOBOX-SRQ already provide security recommendations. The questionnaire
(appendix A) should be extended by a description on how to configure logrotation and log
forwarding to syslog(8).
Security incompatibilities
There are several daemons running on the VO-boxes which are provided and maintained
by the VOs. Some of these daemons are listening on network ports which are opened for
inbound connections from world.
Up to now (spring 2009) there is either no logging of VO daemons enabled at all, or the
collection of logfiles is not properly handled according to the Audit Requirements. For
instance, logfiles are deleted after a few days already. Redirection to the local syslog(8)
facility isn't implemented and configured yet.
List of externals (packages are NOT maintained by Red Hat or by gLite)
!!! INCOMPLETE !!!
This part should be accomplished by the respective developers of the VOs.
Other security relevant comments
There are currently a lot of documents about VO-boxes published at different places.
Utility scripts
Nothing reported.
Location of reference documentation
Developer Documentation