Building an Odum Secure Enclave.

One of the Odum Institute’s primary responsibilities in the ImPACT project was to stand up a local instance of the technology behind Duke’s Protected Research Data Network, or PRDN. Duke’s full PRDN supports Shibboleth authentication, requires Active Directory customization not provided by our university and needs its own VLAN protected by hardware firewall, so while we worked with the university to prepare these services we endeavored to stand up a simpler “abridged” PRDN to evaluate its utility for organizations which lacked the resources or access to stand up the full PRDN, henceforth known as the “Odum Enclave.”

For the abridged enclave we settled on SSH forwarding from a bastion host, used to launch a TurboVNC client from the enclave-protected VM back to the user’s workstation. As with any setup there are strengths and weaknesses:

Abridged Enclave

Strengths:

  • Simple to implement, free / open source software
  • Easy to use for those familiar with the command line
  • TurboVNC supports hardware-acceleration via OpenGL

Weaknesses:

  • From a security perspective, all users share the bastion host
  • Not easy to use for those unfamiliar with the command line
  • No built-in data-access auditing; entries in standard Linux system logs

With our Shibboleth SP registered, VLAN and firewall rules in place, and our Active Directory controller ready we turned our attention to implementing the full enclave, using Rob Carter’s excellent “Proconsul/Dockerized” GitHub repository. Despite having the Proconsul web application provided in a Docker container, the instance required a significant amount of debugging, mostly related to authenticating temporal Active Directory users to Linux target VMs through SSSD. We have extensive notes from this process and can make them available on request.

As our target VMs all run CentOS Linux rather than Windows, we were able to use Singularity as a mechanism to provide vetted applications. In this workflow, Singularity source files may be pushed to our GitHub repo by a developer with write access. GitHub in turn calls a webhook into our Jenkins CI, which then attempts to build the container. On success, Jenkins pushes the resulting Singularity image into our Singularity Hub inside our secure enclave, where it becomes searchable and accessible to each of the target Linux workstation VMs.

Singularity provided us with flexibility of application access without requiring local installation on the VM, but its command syntax may flummox less experienced users.

Current Odum Enclave

Strengths:

  • Provides web-based, graphical access to target VMs using UNC SSO
  • Users may easily launch certain popular containers via menu icons
  • Web-based administration makes configuring user access easy for an archivist or gatekeeper
  • All user access logged in a MySQL database

Weaknesses:

  • Current UNC policy forbids the creation of temporary accounts in Active Directory, so we had to stand up our own Active Directory controller and perform all the reverse-engineering and debugging required to make the Linux target VMs authenticate through SSSD.
  • Session disconnects from the target VMs are common, even with screensavers and power management services disabled.
  • End users who aren’t comfortable with the command line will only be able to launch prescribed/scripted Singularity containers; others aren’t happy with the vanilla state of Python and R containers and want their package sets customized.

At this point we have a full, working installation. However, in the Duke PRDN a team of archivists approve data access requests, manually grant target VM access to end users, and stage the data inside the protected secure enclave. ImPACT members are working on services to automate such decisions; we look forward to implementing and evaluating these as well.