Skip to main content

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


Comments

Post a Comment

Popular posts from this blog

GoF patterns

Why learn GoF Design Patterns? Design patterns help you find out patterns in your code. It helps to visualize your code at a higher level and decompose it into logical units.   What are Design Patterns? Design patterns are canonical solutions to recurring problems. They are different from a library that is called from your code. Neither are they framework which is a complicated collection of libraries. Frameworks typically calls your code. The 24 design patterns covered in GoF book can be divided into three categories. Creational Patterns . These patterns seek to answer - "How should objects be created?".  Examples are - Factory, Abstract Factory, Singleton, Builder, Prototype, Dependency Injection. They usually seek to decouple the construction of an object from its use. There are advantages to doing this. Hide implementation of an object, only reveal its interface.  Defer instantiation until run-time.  Allow creation of finite number of instances.  Have f...
Post a Comment
Read more

Git Workflow For Multiple Repositories

Introduction Imagine a situation where you have to work off multiple repositories hosted on multiple hosts. Let us say there are two hosts - ALM and Cloudlab. These repositories on these hosts are managed by two separate teams - ALM and Policy respectively. By setting up a Git workflow across Cloudlab and ALM instances, we can create a development environment for Policy developers working on ATS. This allows them to make changes to the  step files  and approve them within Policy team. Both teams - Policy and ALM, can work independently.  All development and code review is done in the Cloudlab instance. Once changes pass the team's quality assurance review, they are deployed to ALM instance as desired.  This article describes the method for Setting up a Git workflow among multiple repositories across Cloudlab and ALM How to keep those repositories in sync How to use another repo within a given repo Developer Workflow The overall process is as follows: Create a lo...
Post a Comment
Read more