Jenkins CI Pipeline for Security Scans

This document describes the set of Jenkins CI Pipeline steps currently in use.

Context Diagram

Jenkins Workflow

OCCNE CI Job

1. Gradle Build - using gradle, the available source is scanned using OWASP dependency checker, then a number of docker containers are created.
2. Static Scan - using the McAfee malware scanner container (created in the Gradle Build step), all created docker containers are scanned for malware.
3. Verify Build - Each docker container is loaded and the self test method is executed.
4. Deploy - An OCCNE Deployment job is created and invoked.  (OCCNE CI Jobs may run in parallel - OCCNE Deploy Jobs are serialized.)

OCCNE Deploy Job

1. Prepare Deploy - Wipe out any old cluster artifacts - get ready for a fresh deploy
2. for (container in OS_Install, DB_Install,. K8s_install, Cfg_Install) do:
   1. Deploy_{{container}} - runs the named docker container
   2. Test_Deploy_{{container}} - verifies that the docker container operations were successful
3. Scan CNE - using the cne_scan container, invoke the selected scan suites against the deployment target.

Here is an overview of the various deployment containers:

• OS_Install - Loads and hardens an OS distribution onto the deployment target
• DB_Install - Installs DBMS Software (MySQL) onto the DBMS deployment targets
• K8S_Install - Installed Kubernetes onto the K8s deployment targets
• Cfg_Install - Installs Common Service Components onto various deployment targets
• CNE_Scan - deploys and executes a set of security scanners onto the deployment target

In general, the deployment targets are specifies using an Ansible host inventory file, and the deployment actions are encoded as Ansible playbooks delivered by the deployment container.

Container Self-Test

Each of the OC-CNE containers is delivered with a pair of tests pre-configured:

• self-test - run in the Verify Build step, the self-test confirm that the container was built more or less correctly
• cluster-test - run in the Test_Deploy_{{container}} step, the cluster tests confirm that the container payload was successfully installed on the deployment target system.

These container test tests are quite simple and do not perform and significant behavioral or functional tests.  Any complex testing will be performed using one or more dedicated test containers.  (In general, we do not want to deliver any complex test suites prepackaged in the application containers - tests should not be delivered or installed on customer sites per Oracle OSSA Guidelines.)

Dedicated Scan Container (CNE Scan)

When we want to verify CNE security posture, we will deliver a set of security scans to the target an run them. The scan container works similarly to the deployment containers - it uses the same Ansible host inventory file, and the scan actions are run via an Ansible Playbook.   The scans are organized into a suites, each suite documented by a playbook.  The playbook defines a number of Ansible tasks, each of which implement a specific scan in the scanner suite.

Initially, the following scanner suites are planned:

• cis - Verifies the general hardening of the system; the following tests are available:
  • kube-bench - invokes the Kubernetes CIS conformance tests on worker and master node in the cluster
  • docker-bench-security - invokes the Docker CIS conformance tests on a node in the cluster
• scap - performs a set of Security Content Automation Protocol (SCAP) driven tests
  • oval - performs an vulnerability assessment using published Common Vulnerabilities and Exposure (CVE) data
  • xccdf-standard - performs the standard configuration security assessment. (The Extensible Configuration Checklist Description Format (XCCDF) is a standard format for defining security checks.)
  • xccdf-rht-ccp - performs the standard Oracle Linux 7 Cloud Provider Security Scan
  • xccdf-stig-rhel7-disa - performs the Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) scans for Oracle Linux 7.

Using the CNE_SCAN_ARGS, Ansible tags can specified allowing for a specific suite or scan to be performed; here are some examples:

• --tags=cis - runs just to cis scans
• --skip-tags=cis - runs all the scans except for the cis scans
• --tags=scap --skip-tags=oval - runs all of the scap scans, except for the oval scan.

The following tags have been defined and may be used to select scans:

• cis
  • kube-bench
  • docker-bench-security
• scap
  • oval
  • xccdf
    • xccdf-standard
    • xccdf-rht-ccp
    • xccdf-stig-rhel7-disa