

Kerberos

If your workflow needs to access external services from within the job such as EOS you could use Kerberos authentication.

Generating keytab file

First, generate a Kerberos keytab file for passwordless authentication.

$ # login to lxplus and generate keytab file
$ ssh johndoe@lxplus.cern.ch
$ ktutil
ktutil:  add_entry -password -p johndoe@CERN.CH -k 1 -e aes256-cts-hmac-sha1-96
Password for johndoe@CERN.CH:
ktutil:  add_entry -password -p johndoe@CERN.CH -k 1 -e arcfour-hmac
Password for johndoe@CERN.CH:
ktutil:  write_kt .keytab
ktutil:  exit

$ # Let's test generated keytab file by trying to generate Kerberos ticket
$ scp johndoe@lxplus.cern.ch:~/.keytab .
$ kinit -kt ~/.keytab johndoe@CERN.CH
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: johndoe@CERN.CH

Valid starting       Expires              Service principal
04/29/2019 11:24:12  04/30/2019 12:23:52  krbtgt/CERN.CH@CERN.CH
  renew until 05/04/2019 11:23:52
04/29/2019 11:24:49  04/30/2019 12:23:52  host/tweetybird04.cern.ch@CERN.CH
  renew until 05/04/2019 11:23:52
04/29/2019 11:25:00  04/30/2019 12:23:52  host/bigbird14.cern.ch@CERN.CH
  renew until 05/04/2019 11:23:52

Uploading secrets

Once you have a working keytab file, you need to upload your CERN username and keytab secrets to REANA:

$ reana-client secrets-add --env CERN_USER=johndoe \
                           --env CERN_KEYTAB=.keytab \
                           --file ~/.keytab

Setting Kerberos requirement

Setting Kerberos requirement for whole workflow

If the workflow engine you are using needs Kerberos to parse and validate the workflow specification, then you can enable it globally for the whole workflow orchestration in the reana.yaml file. For example, this may be needed if you are using the Snakemake workflow engine with data objects living in a restricted data storage:

workflow:
  type: snakemake
  resources:
    kerberos: true
  file: workflow/snakemake/Snakefile

This will enable Kerberos authentication not only for workflow orchestration, but also for each workflow step job.

Setting Kerberos requirement for certain jobs only

If your workflow does not need Kerberos for the whole duration, but only for some of its steps, you can provide a workflow hint kerberos: true for only those steps that need it.

Serial example:

workflow:
  type: serial
  resources:
    cvmfs:
      - fcc.cern.ch
  specification:
    steps:
      - environment: "cern/slc6-base"
        kerberos: true
        commands:
          - ls -l /cvmfs/fcc.cern.ch/sw/views/releases/

CWL example:

steps:
  first:
    hints:
      reana:
        kerberos: true
    run: helloworld.tool
    in:
      helloworld: helloworld

      inputfile: inputfile
      sleeptime: sleeptime
      outputfile: outputfile
    out: [result]

Yadage example:

step:
  process:
    process_type: "string-interpolated-cmd"
    cmd: 'python "{helloworld}" --sleeptime {sleeptime} --inputfile "{inputfile}" --outputfile "{outputfile}"'
  publisher:
    publisher_type: "frompar-pub"
    outputmap:
      outputfile: outputfile
  environment:
    environment_type: "docker-encapsulated"
    image: "python"
    imagetag: "2.7-slim"
    resources:
      - kerberos: true

Snakemake example:

rule helloworld:
  input:
    helloworld=config["helloworld"],
    inputfile=config["inputfile"],
  params:
    sleeptime=config["sleeptime"]
  output:
    "results/greetings.txt"
  resources:
    kerberos=True
  container: "docker://python:2.7-slim"

Please note that Kerberos token is automatically provided for HTCondor and Slurm compute backend jobs and there is no need to specify kerberos requirement in the workflow specification.