Argus Global Banning Setup Overview

From PDP/Grid Wiki
Jump to navigationJump to search

Introduction

This page is a *DRAFT*. Furthermore, this page is not intended to give a full overview of how to install an Argus service, see instead https://twiki.cern.ch/twiki/bin/view/EGEE/ArgusEMIDeployment for information on general setup.

Architecture / Components

Central wLCG instance
for the purpose of this wiki an Argus PAP is sufficient (no PDP or PEPd)
NGI Argus instance
unless all its sites run an Argus, a full Argus (with PDP and PEPd) is needed.
Site services
Site either runs its own Argus, or defines local mapping rules combined with NGI-based banning.

Setup

Configuring a PAP

An Argus PAP can be configured using either the pap-admin cli tool, see https://twiki.cern.ch/twiki/bin/view/EGEE/AuthZPAPCLI or directly via the ini files pap_authorization.ini (for the ACL) and pap_configuration.ini (for setting remote PAPs), both located in etc/argus/pap.

For setting the policies, the pap-admin is the only option.

Note: When using YAIM to configure Argus, it will be left without any policy.

Central wLCG Argus

  • The Central wLCG Argus needs to be configured to have a policy which *only* bans (/deny entries) subjects and/or FQANs.
  • In addition it needs to have an appropriate ACL which permits all the NGI Argus PAPs read access to its policy.

Configuring the ACL in the central banning PAP

The central banning Argus PAP needs to have a access control entry for each of the NGI Argus instances. Each of these must have read access to the "local" policy in the central Argus PAP.

Adding a new ACE for argus-ngi with the LDAP notation for its DN: 

pap-admin add-ace 'CN=argus-ngi.testbed, OU=testbed, O=hosts, O=Test CA' POLICY_READ_LOCAL

The DN will be internally translated into OpenSSL format.

Check the new list of ACEs, note that the output uses the OpenSSL notation, which cannot be used as input. 

pap-admin list-acl

Alternatively a line can be added to the [dn] section in the /etc/argus/pap/pap_authorization.ini file, e.g.: 

[dn]
"/O=Test CA/O=hosts/OU=testbed/CN=argus-ngi.testbed" : POLICY_READ_LOCAL

When updating the pap_authorization.ini file directly, the service needs to be restarted. The CLI tool on the other hand, does not require a reboot and will update the ini file.

Setting up the policy in the PAP

The central banning policy will be very simple. Normally, it should be valid for any resource and action ID (see https://twiki.cern.ch/twiki/bin/view/EGEE/AuthZIntro#Identifiers_within_Argus for background information), i.e. for ".*". Banning a user: 

pap-admin ban subject "CN=John Doe, O=nikhef, O=users, O=dutchgrid"

Which will create a policy in the 

default (local):

section containing: 

resource ".*" {

    action ".*" {
        rule deny { subject="CN=John Doe, O=nikhef, O=users, O=dutchgrid" }
    }
}

For banning a large list of subjects (or FQANs) it is probably useful to create a file containing a policy such as above with many deny lines, and use the command 

pap-admin add-policies-from-file <ban-policy-file>

where ban-policy-file contains the banning policy. add-policies-from-file can be abbreviated to apf.

Unbanning can be done using 

pap-admin unban subject "CN=John Doe, O=nikhef, O=users, O=dutchgrid"

The active policy can be viewed with 

pap-admin list-policies

where list-policies can be abbreviated to lp. Note that policies are parsed in the order printed, until a match is found.

NGI Argus

Adding the central banning Argus PAP to the list of PAPs

The NGI Argus PAP needs to use the central banning Argus as input. It can be added using the CLI by specifying a alias, its hostname and DN. In this case the DN *must* be in OpenSSL notation. Also note that it needs to be added 'public' since the sites need to be able to read the central Argus' policy: 

pap-admin add-pap --public centralbanning argus-cern.testbed "/O=VL-e P4/O=hosts/OU=testbed/CN=argus-cern.testbed"

After this, the new PAP needs to be enabled: 

pap-admin enable-pap centralbanning

And the central banning PAP needs to be ordered first: 

pap-admin set-paps-order centralbanning default

Alternatively the configuration can be added to the /etc/argus/pap/pap_configuration.ini file: 

[paps]
centralbanning.type = remote
centralbanning.enabled = true
centralbanning.dn = /O=VL-e P4/O=hosts/OU=testbed/CN=argus-cern.testbed
centralbanning.hostname = argus-el6-64.testbed
centralbanning.port = 8150
centralbanning.path = /pap/services/
centralbanning.protocol = https
centralbanning.public = true

[paps:properties]
poll_interval = 3600 # polling time in seconds.
ordering = centralbanning
ordering = default

followed by a restart of the PAP service. A forced retrieval of the remote policies can be triggered using 

pap-admin refresh-cache

TODO: figure out the best polling interval. Defaults is 14400 (i.e. 4 hours).

Configuring the ACL in the NGI PAP

The NGI Argus PAP needs to be setup with ACEs in the same way as the Central Argus, except it needs to allow read access (also) for remote policies. In case the NGI would also like to keep a local list of banned users, the ACE should be setup as in 

pap-admin add-ace 'CN=argus-site.testbed, OU=testbed, O=hosts, O=Test CA' 'POLICY_READ_LOCAL|POLICY_READ_REMOTE'

Alternatively a line can be added to the [dn] section in the /etc/argus/pap/pap_authorization.ini file, e.g.: 

[dn]
"/O=Test CA/O=hosts/OU=testbed/CN=argus-site.testbed" : POLICY_READ_LOCAL|POLICY_READ_REMOTE

Followed by a restart of the PAP service.

Policies in the NGI Argus

The NGI Argus can add local banning rules just as the Central Banning Argus, and these will be also taken into account by the site Argus instances. Also in this case it is advisable not to use a specific resource ID but just use the catch-all ".*".

The banning Argus PAPs, either central or NGI, should **not** put obligations in their policies, unless they really know what they are doing. Especially the "http://glite.org/xacml/obligation/local-environment-map" mapping oligation will lead to problems. In addition, the NGI Argus should have no obligationHandlers configured in the corresponding PEPd configuration file /etc/argus/pepd/pepd.ini as a further protection.

In case the NGI Argus is also used to provide the actual mappings for the sites (this is a difficult and not-advisable setup) this could be done in non-generic resource ID entries, where the banning is done in the catch-all ".*" resource ID section.

TODO: Need to check that the less-generic policy is still used when the more-generic has no match.

NGI PDP configuration

When a site will not run its own Argus service, it will most likely want to query the NGI Argus via the PEPd frontend and a complete PAP+PDP+PEPd Argus will be setup by the NGI. The PDP will query the PAP from time to time, and cache the policy. This retentionInterval time defaults to 240 minutes (i.e. 4 hours) and can be set in /etc/argus/pdp/pdp.ini in the [POLICY] section. After an update, the PDP needs to be restarted.

A update can be triggered by hand using 

/etc/init.d/argus-pdp reloadpolicy

TODO: what would be a reasonable time?

Site

Site runs own Argus

When the site runs its own Argus instance, it should be sufficient to add the NGI Argus as a remote PAP and configure it to be the leading PAP, following the same commands as above: 

pap-admin add-pap ngi argus-ngi.testbed "CN=argus-ngi.testbed,OU=testbed,O=hosts,O=VL-e P4"
pap-admin enable-pap ngi
pap-admin set-paps-order ngi default

Additionally, the polling interval needs to be set to a reasonable value, to be decided: 

pap-admin set-polling-interval 3600

And also the retentionInterval for the site PDP, in the pdp.ini file, as described above.

Note that the only reason the site would not directly use the central banning PAP is the difficulty in maintaining the ACL in the central banning PAP.

After adding the NGI PAP, the resulting combined policy can be viewed using 

pap-admin lp --all

The additional --all is necessary to include the remote policies.

Site runs no Argus

There are roughly two options available:

  1. The site downloads e.g. via cron, the banlist from NGI (Argus). It uses this with, for example, the LCMAPS lcmaps_ban_dn plugin (part of lcmaps-plugins-basic-1.5.1 or higher) or the LCAS lcas_userban plugin.
  2. The site runs first the LCMAPS C-PEP plugin which will listen to the NGI Argus and then uses other LCMAPS plugins (e.g. SCAS or local mappings) for obtaining the user mapping. There are some complications with this, but a solution is being prepared, see below.

Using lcmaps-plugins-c-pep

To use an Argus only for banning leads to some complications. The reason is that in such case the result of the combined effective Argus policy will be either Deny (user is on banlist) or Not Applicable (user is not on banlist). On the other hand, Argus is designed to typically result in either a Deny or Permit. The results Not Applicable (no match) and Indeterminate (parse error) are treated as failure, see https://twiki.cern.ch/twiki/bin/view/EGEE/AuthZIntro#Not_Applicable_and_Indeterminate.

A solution could have been to define a policy that ends with an explicit permit line catching everyone not on the banlist. This is non-trivial:

  1. After the first match the rest of the policy is not being parsed, so this cannot be naively done on the NGI Argus if the same policy is being imported by site Argus instances. A possible workaround would be to put the "permit" line under a special "resource" definition, while the banlist is under the catch-all resource ".*". The LCMAPS C-PEP plugin would then specify the special resource, while sites with their own Argus would use their own resource identifier.
  2. It seems impossible to define a 'catch-all' policy: Argus does not seems to honour a wilcard in a subject definition (NOTE: this is being checked with the Argus developers).

As a more robust solution, a new option has been introduced into the lcmaps-plugins-c-pep-1.2.4. When specified, a Not Applicable will be interpreted as success. The option can be called with either --banning-only-mode or --treat-notapplicable-as-success.

The plugin will be released for EMI and UMD. It can be found in the Nikhef repository, currently in testing, 

http://software.nikhef.nl/dist/mwsec/rpm/

available for RHEL5 and 6, Fedora 17, 18 and 19.

The typical definition in the lcmaps.db file would be something like: 

 pepc        = "lcmaps_c_pep.mod"
             "--pep-daemon-endpoint-url https://argus-ngi.testbed:8154/authz"
             "--resourceid anything"
             "--actionid something"
             "--capath /etc/grid-security/certificates"
             "--pep-certificate-mode implicit"
             "--use-pilot-proxy-as-cafile" # Add this on RHEL 6 based systems
             "--banning-only-mode" # use *ONLY* when Argus is used for banning only
Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=Argus_Global_Banning_Setup_Overview&oldid=9106"