Skip to content

Overview

Technical requirements

Nullafi Shield requires minimal resources to deploy, although requirements increase according to the scale of the deployment. The following list is sufficient for a typical customer.

Server Requirements

  • Linux host with Docker or compatible container runtime
    • [OPTIONAL] Docker Compose for ease of configuration and management
  • At least 4GB RAM and 4GB storage

Other Services

  • ICAP Client
    • Any typical proxy server can be configured as an ICAP client for Request and Response Modification
      • Secure Web Gateways are commonly already processing user traffic
  • [OPTIONAL] User/Group directory
    • Without directory integration, Nullafi Shield can be configured with global policy that applies to all users
    • Directory integration requires either that the proxy be configured to authenticate users and to modify HTTP headers in ICAP connections to include user/group information, or that Nullafi Shield be configured to use SAML authentication to your directory.

Network Environment

  • User traffic flowing through the proxy
    • Each proxy has it's own configuration options, so methods of getting user traffic to the proxy will differ.
    • Using Squid Proxy as an example:
      • Connectivity from client devices to the Squid Proxy (on any port; default is 3128)
      • Connectivity from the Squid Proxy to any web applications to be used (typically ports 80 and/or 443)
      • [OPTIONAL] certificate signed by a trusted CA for use by the Squid Proxy, or acceptance of Squid’s self-signed certificate
  • ICAP connections from proxy to ICAP server
    • Connectivity from the proxy to Nullafi Shield on at least one port (typically 1344) for plain text ICAP connections
    • [OPTIONAL] connectivity from the proxy to Nullafi Shield on an additional port for SSL encrypted ICAP connections
  • Administration Console access connectivity from administrator’s PC to Nullafi Shield
    • HTTPS for SSL encrypted configuration management (typically 443)
    • HTTP for plain text configuration management (typically 80)
  • [OPTIONAL] User traffic connectivity to an Identity Provider (IdP) for directory integration
    • Nullafi Shield can be configured to authenticate users via SAML redirects. In this case, the End Users' browsers need to be able to connect to the IdP (typically via HTTPS on port 443).

Software requirements

Nullafi Shield is distributed in a containerized form factor. Without getting into the complexities of the many options regarding container runtimes and host operating systems, Nullafi tests with containerd. If you’re not intimately familiar with container runtimes and the difference between OCI and CRI and a hundred other acronyms, it’s enough to know that you can use Docker and Kubernetes with Nullafi Shield. If you are familiar with those terms, then you don’t need us to tell you how to make it work.

For any configuration examples going forward in this document, we’ll assume you are using Docker (in fact, we’ll use Docker Compose yaml format because it’s fairly easy to read) and leave any translation from that to other tools to you.

Deployment

Using a simple Docker Compose file, it is easy to bring up an instance of Nullafi Shield in your environment. There are a few mandatory configuration parameters which must be included when the container is started. Other options are configurable but not required; Shield will use default values if they are not specified. These are documented in the Container Options section.

Shield relies upon two databases; one for configuration and the other to store Activity data. While these can reside anywhere, the sample compose files will bring up containerized databases alongside the Sheild container.

The sample Docker Compose file can be used to start an instance of Nullafi Shield by issuing the command docker-compose up -d “up” tells Docker Compose to start the containers referenced in the comose file, and “-d” says to run in Detached mode.

Product Updates

Standard practices for managing containers include the concept of replacing containers rather than upgrading them. When new versions of Nullafi Shield become available, running the new version is as simple as downloading the new container image and then redeploying from your deployment script. When using Docker Compose to deploy an upgrade, an upgrade can be accomplished in two commands: 

docker-compose pull
docker-compose up -d
Pull tells Docker to go get the new image. Running “up -d” a second time will only recreate changed images (so if your compose file defines many containers and services, it will only stop and restart images that have changed since the last “up -d” run.

Optionally, you might use: 

docker image prune
to remove obsolete images.