Difference between revisions of "User:Dennisvd@nikhef.nl/lijmwijzer"

From PDP/Grid Wiki
Jump to navigationJump to search
m
 
(25 intermediate revisions by the same user not shown)
Line 1: Line 1:
De LCMAPS lijmwijzer. Nederlandse tekst is concepttekst.
+
= The Administrator's guide to grid security middleware =
  
 +
* [[Security middleware deployment planning]] Which services should you install on your site? How is authorization centrally arranged? If you have no idea where to begin, start here to find out which services you are likely to be needing.
 +
* [[Configuring services for use with Argus]] If you are using Argus on your site, this chapter will explain how to configure services as Argus clients.
 +
* [[Configuring services for use with SCAS]] If you are using [[SCAS]] on your site, this chapter will help you configure services to use it.
 +
* [[Configuring services for node-local mapping]] This chapter explains the configuration of [[LCMAPS]] as a stand-alone component.
 +
* [[Configuring services for use with GUMS]] The GUMS service (used in OSG) client configuration is explained here.
  
 +
== How to use this guide ==
  
== The universal guide to setting up Grid user authorization at your site ==
+
The material in this guide will help you set up the basic grid security middleware. If you already know ''what'' you want, just follow the links to the relevant chapters. If you are not sure which services you should set up and are confused by the options, start by reading the chapter on [[Security middleware deployment planning]] after which you should be able to make a well-founded decision on how proceed.
  
This guide will help you choose and configure security middleware components to suite the local setup at your site. ''Warning:'' this guide will
+
This guide will not explain how to set up site security in general.
''not'' explain how to set up site security in general.
 
  
The following text applies to sites that are part of the EGEE grid infrastructure. For other Grids, a separate guide will be provided.
+
=== Prerequisites ===
  
We need to distinguish current practice from upcoming methods; we
+
This guide is aimed at grid site administrators. Although it contains ready-to-use example configurations that should result in a working setup, the advised way to configure middleware is through the use of YAIM and some knowledge of the use of YAIM is assumed. The guide will indicate which examples will be produced by YAIM, and which will have to be done manually.
project the direction taken by new developments, but as some
 
features are not yet supported, or never will be, the old style
 
alternatives must be discussed alongside.
 
  
The old is perhaps best represented by the [[LCAS]]/[[LCMAPS]] family of
 
software, accompanied by [[SCAS]] an [[gLExec]]. This collection of system
 
tools and libraries is developed in C, and has deep roots in the
 
earliest grid systems. While the software proved to be stable
 
grounds, some of the more recent wishes were hard to express in
 
configuration and setup, and over time the authorization system was
 
rethought and rewrought as the [https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework Argus] service.
 
  
The new service complements the older codes, not replaces them;
+
The following text applies to sites that are part of the EGEE grid infrastructure[http://www.eu-egee.org/]. For other Grids, a separate guide will be provided.
except for [[SCAS]] which was always supposed to be only a steward
 
until the arrival of its master.
 
  
=== Step 1: central authorization ===
+
[[Old versus New]]
  
=== Step 2:
 
  
 +
=== Step 2: Resource configuration ===
 +
 +
Depending on the selections in step 1, apply the detailed configurations below.
 +
 +
The configurations are marked with symbols to indicate how well they are supported:
 +
* {{InProduction}} Configurations with this marker are found in production systems all over, and are proven to work well.
 +
* {{YAIMConfigurable}}
 +
* {{Certified}}
  
 
=== Central account mapping ===
 
=== Central account mapping ===

Latest revision as of 14:06, 22 April 2010

The Administrator's guide to grid security middleware

How to use this guide

The material in this guide will help you set up the basic grid security middleware. If you already know what you want, just follow the links to the relevant chapters. If you are not sure which services you should set up and are confused by the options, start by reading the chapter on Security middleware deployment planning after which you should be able to make a well-founded decision on how proceed.

This guide will not explain how to set up site security in general.

Prerequisites

This guide is aimed at grid site administrators. Although it contains ready-to-use example configurations that should result in a working setup, the advised way to configure middleware is through the use of YAIM and some knowledge of the use of YAIM is assumed. The guide will indicate which examples will be produced by YAIM, and which will have to be done manually.


The following text applies to sites that are part of the EGEE grid infrastructure[1]. For other Grids, a separate guide will be provided.

Old versus New


Step 2: Resource configuration

Depending on the selections in step 1, apply the detailed configurations below.

The configurations are marked with symbols to indicate how well they are supported:

  • Currently in production Configurations with this marker are found in production systems all over, and are proven to work well.
  • YAIM configurable
  • Certified configuration

Central account mapping

Managing the (pool) user and group account mappings on a site is typically done centrally. If for some reason a central authorization service is not chosen, the gridmapdir and/or groupmapdir could be shared (with NFS) among all services where mappings are performed, for consistency.

Node-local mapping

In special cases the scope of the account mappings is kept local to a node; these use-cases are typically found when users are mapped to a job slot on a worker node. Node local mapping can be mixed with centralized mapping, for instance when using secondary group ids from the central group mapping.

Special Cases

The following items should be considered before a final choice can be made.

LDAP enforcement

The LCMAPS plugin for LDAP enforcement is used for sites that have dynamic mappings to users and groups, which requires a modification of the LDAP database every time a (new) mapping is done. Zie elders. Applies to: WN, CE.

This plugin will not work together with the ARGUS framework. Currently in production Certified configuration


LDAP enforcement with SCAS

(This situation is supposed to work, but not found in production as such.)

On the WN:

get_account_on_wn:
verify_proxy -> scas_client
scas_client -> ldap_enf
ldap_enf -> posix_enf

On the CE:

get_account_on_ce:
scas_client -> ldap_enf
ldap_enf -> posix_enf

On SCAS:

get_account_on_scas:
voms_pool_group -> voms_local_group | voms_local_group
voms_local_group -> voms_pool_account

LDAP enforcement with node-local mapping

On the WN:

get_account_on_wn:
verify_proxy -> voms_pool_group | voms_local_group
voms_pool_group -> voms_local_group
voms_local_group -> voms_pool_account
voms_pool_account -> ldap_enf
ldap_enf -> posix_enf

On the CE:

get_account_on_ce:
voms_pool_group -> voms_local_group | voms_local_group
voms_local_group -> voms_pool_account
voms_pool_account -> ldap_enf
ldap_enf -> posix_enf

AFS integration

If your site makes use of AFS for file access (e.g. AFS home directories that require AFS tokens) then you need the AFS enforcement plugin. Applies to: CE, WN.

using an ARGUS backend

On the WN:

get_account_on_wn:
verify_proxy -> pepc
pepc -> afs_enf
afs_enf -> posix_enf

On the CE:

get_account_on_ce:
pepc -> afs_enf
afs_enf -> posix_enf

using a SCAS backend

On the WN:

get_account_on_wn:
verify_proxy -> scas_client
scas_client -> afs_enf
afs_enf -> posix_enf

On the CE:

get_account_on_ce:
scas_client -> afs_enf
afs_enf -> posix_enf

On SCAS:

get_account_on_scas:
voms_local_group -> voms_pool_account

AFS enforcement with node-local mapping

This case is used when there is no centrally arranged authorization; the gridmapdir should be shared (e.g. through NFS) between services for consistent mappings.

On the WN: Certified configuration Currently in production YAIM configurable

get_account_on_wn:
verify_proxy -> voms_local_group
voms_local_group -> voms_pool_account
voms_pool_account -> afs_enf
afs_enf -> posix_enf

On the CE:

get_account_on_ce:
voms_local_group -> voms_pool_account
voms_pool_account -> afs_enf
afs_enf -> posix_enf

Third party plugins

Some sites use LCMAPS plugins not provided with the base LCMAPS software; the functioning and side-effects of such plugins is specific to the site and the implementation. In general, it cannot be determined a priori if a plugin will or will not work with either ARGUS or SCAS. YMMV.


Service types

Worker Node

Compute Element

CREAM CE

There are two services that independently use LCMAPS on a CREAM CE: gLExec and gridftpd. It is vital that mappings for both are consistent, otherwise e.g. proxies and sandboxes cannot be read. Differences between the configuration for gLExec and the gridftpd are allowed only if the flow of the plugin execution and the initialization parameters of the plugins result in a consistent mapping.

Examples:

gridftpd:

withvoms:
vomslocalgroup -> vomslocalaccount
vomslocalaccount -> posix_enf | vomspoolaccount
vomspoolaccount -> posix_enf

standard:
localaccount -> posix_enf | poolaccount
poolaccount -> posix_enf

gLExec:

withvoms:
verify_proxy -> vomslocalgroup
vomslocalgroup -> vomslocalaccount
vomslocalaccount -> posix_enf | vomspoolaccount
vomspoolaccount -> posix_enf

standard:
verify_proxy -> localaccount
localaccount -> posix_enf | poolaccount
poolaccount -> posix_enf


LCG-CE

Storage Element

Workload Management System