Argus Global Banning Setup Overview

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

TODO: There is a problem here: if the NGI Argus does not match anything, i.e. if it does not explicitly permit or deny the user, the PDP/PEPd will return a NotApplicable, which leads to a failing lcmaps-plugins-c-pep. This is in line with the Argus wiki [https://twiki.cern.ch/twiki/bin/view/EGEE/AuthZIntro#Not_Applicable_and_Indeterminate] which states that a NotApplicable is a failure. Adding a permit line at the end will not work either, as that will then be the only matching entry, which will break matching later in a site-Argus (see [https://twiki.cern.ch/twiki/bin/view/EGEE/SimplifiedPolicyLanguage#How_policies_are_evaluated]

A bugfix in the LCMAPS-plugins-C-pep is being implemented which will allow (via an extra flag) to interpret NotApplicable as success. From the point of view of LCMAPS this also makes sense: if Argus did not result in a mapping, a local plugin might still manage.

Ideally we should have the following:

When the site does not run its own Argus instance, but uses LCMAPS and/or the SCAS for site-local mapping policies, it can still make use of a NGI Argus. In this case, it should configure the lcmaps-plugins-c-pep to run before the local mapping plugins. In the case of using the SCAS, this plugin could be called within the SCAS (which runs LCMAPS centrally). The lcmaps-plugins-c-pep should then be configured e.g. 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