IRS Mini Summit on OpenShift Security

Red Hat IRS Mini Summit 2 (OpenShift Security) 9/18 NCFB Mark Hilburger, Account Exec 703-217-4511 mhilburg@redhat.com Eamon McCormick, Emerging Technologies, 443-413-2719 emccormi@redhat.com

AGENDA 8:00 AM Red Hat overview and team intro Mark Hilburger 8:10 AM OpenShift Architecture and install process Brandon Cox/ Eamon McCormick 9:00 AM IRS Vision Sharon James 9:40 AM OpenShift Demo Patrick Cunning 10:40 AM Break 10:55 AM RHEL and container Security overview Calvin Smith 11:25 AM OSCAP Components Shawn Wells 11:55 AM lunch 12:55 PM OpenShift S2I for Hardened EAP Khary Mendez 1:25 PM CI/CD in OpenShift 1:55 PM Atomic Scan in Jenkins pipeline Khary Mendez Khary Mendez 2:25 PM Break 2:40 PM Scheduling OSCAP Scans for RHEL hosts Cameron Wyatt 3:25 PM OpenControl to automate Security Authorization Package Shawn Wells 4:40 PM end

OpenShift Install and Overview Eamon McCormick

OPENSHIFT ARCHITECTURE ROUTING LAYER SERVICE LAYER SCM (GIT) MASTER NODE NODE PERSISTENT STORAGE NODE C Cc API/AUTHENTICATION CI/CD DATA STORE C C RHEL SCHEDULER EXISTING AUTOMATION TOOLSETS PHYSICAL OPENSHIFT TECHNICAL OVERVIEW RHEL RHEL NODE C HEALTH/SCALING RED HAT ENTERPRISE LINUX 4 NODE C NODE C REGISTRY C C C RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC HYBRID

YOUR CHOICE OF INFRASTRUCTURE PHYSICAL 5 OPENSHIFT TECHNICAL OVERVIEW VIRTUAL PRIVATE PUBLIC HYBRID

NODES RHEL INSTANCES WHERE APPS RUN NODE NODE RHEL NODE NODE RHEL PHYSICAL 6 OPENSHIFT TECHNICAL OVERVIEW VIRTUAL RHEL PRIVATE RHEL PUBLIC NODE RHEL NODE RHEL HYBRID

APPS RUN IN CONTAINERS NODE NODE Container Image NODE C Cc C Container C RHEL NODE RHEL NODE OPENSHIFT TECHNICAL OVERVIEW C C C C RHEL 7 RHEL NODE C Pod C RHEL RHEL

PODS ARE THE UNIT OF ORCHESTRATION NODE NODE NODE C Cc C C RHEL NODE C RHEL RHEL NODE NODE C C C C C RHEL 8 OPENSHIFT TECHNICAL OVERVIEW RHEL RHEL

MASTERS ARE THE CONTROL PLANE NODE MASTER NODE RHEL NODE RED HAT ENTERPRISE LINUX PHYSICAL 9 OPENSHIFT TECHNICAL OVERVIEW NODE RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC NODE RHEL NODE RHEL HYBRID

API AND AUTHENTICATION NODE MASTER NODE NODE API/AUTHENTICATION RHEL NODE RED HAT ENTERPRISE LINUX PHYSICAL 1 0 OPENSHIFT TECHNICAL OVERVIEW NODE RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC RHEL NODE RHEL HYBRID

DESIRED AND CURRENT STATE MASTER NODE NODE NODE API/AUTHENTICATION DATA STORE RHEL NODE RED HAT ENTERPRISE LINUX RHEL RHEL NODE RHEL RHEL NODE RHEL PHYSICAL PHYSICAL VIRTUALVIRTUAL PRIVATEPRIVATEPUBLIC PUBLICHYBRID HYBRID 1 1 OPENSHIFT TECHNICAL OVERVIEW

INTEGRATED CONTAINER REGISTRY MASTER NODE NODE NODE API/AUTHENTICATION DATA STORE RHEL NODE RED HAT ENTERPRISE LINUX PHYSICAL 1 2 OPENSHIFT TECHNICAL OVERVIEW RHEL NODE RHEL VIRTUAL RHEL NODE RHEL PRIVATE REGISTRY RHEL PUBLIC HYBRID

ORCHESTRATION AND SCHEDULING MASTER NODE NODE NODE API/AUTHENTICATION DATA STORE RHEL SCHEDULER RED HAT ENTERPRISE LINUX PHYSICAL 1 3 OPENSHIFT TECHNICAL OVERVIEW NODE RHEL NODE RHEL VIRTUAL RHEL NODE RHEL PRIVATE REGISTRY RHEL PUBLIC HYBRID

PLACEMENT BY POLICY MASTER NODE NODE NODE C Cc API/AUTHENTICATION DATA STORE C C RHEL SCHEDULER RED HAT ENTERPRISE LINUX PHYSICAL 1 4 OPENSHIFT TECHNICAL OVERVIEW NODE RHEL NODE RHEL VIRTUAL RHEL NODE RHEL PRIVATE REGISTRY RHEL PUBLIC HYBRID

AUTOSCALING PODS MASTER NODE NODE NODE C Cc API/AUTHENTICATION DATA STORE C C RHEL SCHEDULER NODE RHEL RHEL NODE NODE REGISTRY HEALTH/SCALING RED HAT ENTERPRISE LINUX PHYSICAL 1 5 OPENSHIFT TECHNICAL OVERVIEW RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC HYBRID

SERVICE DISCOVERY SERVICE LAYER MASTER NODE NODE NODE C Cc API/AUTHENTICATION DATA STORE C C RHEL SCHEDULER NODE RED HAT ENTERPRISE LINUX PHYSICAL 1 6 OPENSHIFT TECHNICAL OVERVIEW RHEL RHEL NODE C HEALTH/SCALING C NODE C REGISTRY C C C RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC HYBRID

PERSISTENT DATA IN CONTAINERS SERVICE LAYER MASTER NODE NODE PERSISTENT STORAGE NODE C Cc API/AUTHENTICATION DATA STORE C C RHEL SCHEDULER NODE RED HAT ENTERPRISE LINUX PHYSICAL 1 7 OPENSHIFT TECHNICAL OVERVIEW RHEL RHEL NODE C HEALTH/SCALING C NODE C REGISTRY C C C RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC HYBRID

ROUTING AND LOAD-BALANCING ROUTING LAYER SERVICE LAYER MASTER NODE NODE PERSISTENT STORAGE NODE C Cc API/AUTHENTICATION DATA STORE C C RHEL SCHEDULER NODE RED HAT ENTERPRISE LINUX PHYSICAL 1 8 OPENSHIFT TECHNICAL OVERVIEW RHEL RHEL NODE C HEALTH/SCALING C NODE C REGISTRY C C C RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC HYBRID

ACCESS VIA WEB, CLI, IDE AND API ROUTING LAYER SERVICE LAYER SCM (GIT) MASTER NODE NODE PERSISTENT STORAGE NODE C Cc API/AUTHENTICATION CI/CD DATA STORE C C RHEL SCHEDULER EXISTING AUTOMATION TOOLSETS PHYSICAL OPENSHIFT TECHNICAL OVERVIEW RHEL RHEL NODE C HEALTH/SCALING RED HAT ENTERPRISE LINUX 1 9 NODE C NODE C REGISTRY C C C RHEL VIRTUAL RHEL PRIVATE RHEL PUBLIC HYBRID

The IRS Deployment 20

INSTALLATION

Installation Process - Ansible ● What is Ansible? ● Ansible Layout of the Advanced installer ○ /etc/ansible/hosts ○ /usr/share/ansible/openshift-ansible/playbooks/byo/config.yml ● Example execution of Ansible playbook for OCP ansible-playbook 2 2 [-i /path/to/inventory] /usr/share/ansible/openshift-ansible/playbooks/byo/config.yml OPENSHIFT TECHNICAL OVERVIEW

Things to Consider ● Which installation method do you want to use? ● How many hosts do you require in the cluster? ● How many pods are required in your cluster? ● Is high availability required? ● Which installation type do you want to use: RPM or containerized? ● Is my installation supported if integrating with other technologies? 2 3 OPENSHIFT TECHNICAL OVERVIEW

Installation Overview ● Installation Methods - Quick Installation vs Advanced Installation ● Sizing Considerations ● Environment Scenarios ○ Single Master - Multiple Nodes ○ Single Master - Multiple Nodes - Multiple etcd ○ Multiple Masters ● RPM vs Containerized 2 4 OPENSHIFT TECHNICAL OVERVIEW

Upgrading A Cluster ● In-place (manual or automated) ○ With in-place upgrades, the cluster upgrade is performed on all hosts in a single, running cluster: first masters and then nodes. Pods are evacuated off of nodes and recreated on other running nodes before a node upgrade begins; this helps reduce downtime of user applications. ● Blue - Green Upgrades ○ masters and etcd servers are still upgraded first, however a parallel environment is created for new nodes instead of upgrading them in-place. 2 5 OPENSHIFT TECHNICAL OVERVIEW

Process for Downgrading a Cluster ● ● ● ● ● ● ● ● 2 6 Verify backups - etcd, config … Shut down the cluster Remove RPM’s Downgrade docker (depends on version of OCP) Reinstall old RPM’s Restore etcd Bring OCP services back on-line Verify that the downgrade was successful OPENSHIFT TECHNICAL OVERVIEW

NETWORKING

BUILT-IN SERVICE DISCOVERY INTERNAL LOAD-BALANCING SERVICE app=payroll 2 8 OPENSHIFT TECHNICAL OVERVIEW role=frontend Name: payroll-frontend IP: 172.10.1.23 Port: 8080 POD POD POD app=payroll app=payroll role=frontend role=frontend app=payroll version=1.0 version=1.0 role=backend

BUILT-IN SERVICE DISCOVERY INTERNAL LOAD-BALANCING SERVICE app=payroll 2 9 role=frontend Name: payroll-frontend IP: 172.10.1.23 Port: 8080 POD POD POD app=payroll app=payroll app=payroll role=frontend role=frontend role=frontend app=payroll version=2.0 version=1.0 version=1.0 role=backend OPENSHIFT TECHNICAL OVERVIEW POD

ROUTE EXPOSES SERVICES EXTERNALLY EXTERNAL TRAFFIC ROUTER INTERNAL TRAFFIC SERVICE POD 3 0 OPENSHIFT TECHNICAL OVERVIEW POD POD

ROUTING AND EXTERNAL LOAD-BALANCING ● Pluggable routing architecture ○ HAProxy Router ○ F5 Router ● Multiple-routers with traffic sharding ● Router supported protocols ○ HTTP/HTTPS ○ WebSockets ○ TLS with SNI ● Non-standard ports via cloud load-balancers, external IP, and NodePort 3 1 OPENSHIFT TECHNICAL OVERVIEW

OPENSHIFT NETWORKING ● Built-in internal DNS to reach services by name ● Split DNS is supported via SkyDNS ○ Master answers DNS queries for internal services ○ Other nameservers serve the rest of the queries ● Software Defined Networking (SDN) for a unified cluster network to enable pod-to-pod communication ● 3 2 OpenShift follows the Kubernetes Container Networking Interface (CNI) plug-in model OPENSHIFT TECHNICAL OVERVIEW

OPENSHIFT NETWORK PLUGINS OPENSHIFT KUBERNETES CNI OpenShift Plugin Flannel Plugin* DEFAULT Nuage Plugin Tigera Calico Plugin Certified Plugin Juniper Contrail Plugin Validated Plugin Cisco Contiv Plugin Big Switch Plugin VMware NSX-T Plugin Open Daylight Plugin In-Progress For a Complete List of Certified Plugins refer to OpenShift Third-Party SDN FAQ * Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift on OpenStack reference architecture 3 3 OPENSHIFT TECHNICAL OVERVIEW

OPENSHIFT SDN FLAT NETWORK (Default) ● All pods can communicate with each other across projects PROJECT A NETWORK POLICY (Tech Preview) NODE NODE POD POD POD POD ✓ ● Granular policy-based isolation Multi-Tenant Network 3 4 OPENSHIFT TECHNICAL OVERVIEW PROJECT C DEFAULT NAMESPACE MULTI-TENANT NETWORK ● Project-level network isolation ● Multicast support ● Egress network policies PROJECT B POD POD POD POD

LOGGING & METRICS

CENTRAL LOG MANAGEMENT WITH EFK ● EFK stack to aggregate logs for hosts and applications ○ Elasticsearch: an object store to store all logs ○ Fluentd: gathers logs and sends to Elasticsearch. ○ Kibana: A web UI for Elasticsearch. ● Access control ○ Cluster administrators can view all logs ○ Users can only view logs for their projects ● Ability to send logs elsewhere ○ External elasticsearch, Splunk, etc 3 6 OPENSHIFT TECHNICAL OVERVIEW

CENTRAL LOG MANAGEMENT WITH EFK NODE OPERATION LOGS POD FLUENTD NODE POD POD ELASTICSEARCH POD NODE RHEL POD ELASTIC ELASTIC POD POD POD RHEL POD POD ELASTIC ELASTIC KIBANA ADMIN APPLICATION LOGS FLUENTD POD FLUENTD POD ELASTIC ELASTIC ELASTICSEARCH ELASTIC ELASTIC KIBANA USER RHEL 3 7 OPENSHIFT TECHNICAL OVERVIEW

CONTAINER METRICS 3 8 OPENSHIFT TECHNICAL OVERVIEW

CONTAINER METRICS NODE POD NODE POD POD NODE RHEL POD POD POD POD RHEL POD POD RHEL 3 9 HAWKULAR OPENSHIFT TECHNICAL OVERVIEW API OPENSHIFT WEB CONSOLE USER CADVISOR POD HEAPSTER FLUENTD POD RED HAT CLOUDFORMS CONTAINER METRICS FLUENTD POD ELASTIC ELASTIC CASSANDRA CUSTOM DASHBOARDS

PERSISTENT STORAGE

PERSISTENT STORAGE ● Persistent Volume (PV) is tied to a piece of network storage ● Provisioned by an administrator (static or dynamically) ● Allows admins to describe storage and users to request storage NFS 4 1 GlusterFS OPENSHIFT TECHNICAL OVERVIEW OpenStack Cinder Ceph RBD AWS EBS GCE Persistent Disk iSCSI Fibre Channel Azure Disk Azure File

PERSISTENT STORAGE POOL OF PERSISTENT VOLUMES register PV iSCSI PV Ceph RBD PV GlusterFS PV NFS PV NFS PV NFS PV Admin PROJECT Pod Pod Pod claim claim claim create claim User 4 2 OPENSHIFT TECHNICAL OVERVIEW

DYNAMIC VOLUME PROVISIONING Slow Azure Provisioner Fast AWS Provisioner Azure-Disk define StorageClass AWS-SSD Admin Fastest NetApp-Flash provision NetApp Provisioner PV Pod create claim: Fastest User 4 3 OPENSHIFT TECHNICAL OVERVIEW OpenShift PV Controller claim bound

CONTAINER-NATIVE STORAGE ● Containerized Red Hat Gluster Storage ● Native integration with OpenShift ● Unified Orchestration using Kubernetes for applications and storage ● Greater control & ease of use for developers ● Lower TCO through convergence ● Single vendor Support 4 4 OPENSHIFT TECHNICAL OVERVIEW APPLICATION CONTAINER APPLICATION CONTAINER APPLICATION CONTAINER STORAGE CONTAINER STORAGE CONTAINER STORAGE CONTAINER DISTRIBUTED, SECURE, SCALE-OUT STORAGE CLUSTER

SERVICE BROKER

WHY A SERVICE BROKER? ☑ Open ticket ☑ Wait for allocation ☑ Receive credentials ☑ Add to app ☑ Deploy app SERVICE CONSUMER SERVICE PROVIDER Manual, Time-consuming and Inconsistent 4 6 OPENSHIFT TECHNICAL OVERVIEW

A multi-vendor project to standardize how services are consumed on cloudnative platforms across service providers 4 7 OPENSHIFT TECHNICAL OVERVIEW

WHAT IS A SERVICE BROKER? SERVICE CONSUMER SERVICE CATALOG SERVICE BROKER Automated, Standard and Consistent 4 8 OPENSHIFT TECHNICAL OVERVIEW SERVICE PROVIDER

OPENSHIFT SERVICE CATALOG OpenShift Template Broker OPENSHIFT SERVICE CATALOG OCP 3.6 TECH PREVIEW OCP 3.7 GA 4 9 OPENSHIFT TECHNICAL OVERVIEW OPENSHIFT Ansible Service Broker ANSIBLE AWS Service Broker AWS Other Service Brokers OTHER COMPATIBLE SERVICES OpenShift Templates Ansible Playbook Bundles AWS Services Other Services

AWS SERVICE BROKER ● Targets Top 10 AWS Services ● Uses Ansible Playbook Bundles ● Available in OpenShift 3.7 5 0 OPENSHIFT TECHNICAL OVERVIEW SQS SNS RDS EMR DynamoDB SNS Lambda RedShift SES S3 ELB

OpenShift Demo Patrick Cunning

RHEL and Container Security Overview Calvin Smith

Security and Compliance Red Hat’s Objective: To deliver the requisite security foundation our customers’ infrastructure, applications, and workloads by providing technology that can be trusted, secured, and compliant. RHEL AND CONTAINER SECURITY OVERVIEW

New trends in IT… Gnome CLOUD Hadoop BIG DATA OpenStack OpenJDK Spacewalk OpenShift Origin Android SDK Apache Project MOBILE RHEL AND CONTAINER SECURITY OVERVIEW Linux Kernel CLOUD APPS

… bring New IT Security Challenges Gnome Data Theft Data locality Hadoop CLOUD BIG OpenStack Identity private / public DATA Processes across boundaries Hybrid IT beyond traditionalOpenJDK IT Spacewalk IT & Application expanded access (api mngt) Distributed IT & Data (mobile / IoT) OpenShift Origin Perimeter security (void?) Android SDK Scale of IT & data Regulations Linux Kernel Apache Project Shadow IT CLOUD MOBILE APPS RHEL AND CONTAINER SECURITY OVERVIEW

“Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years,” - René Gielen, vice president of Apache Struts RHEL AND CONTAINER SECURITY OVERVIEW

IT Governance Provide Users/Business Users a governed IT ● Consumption control : CMP (Cloud Management Platform ) : CloudForms Which resources to access (private / public – high SLA / low SLA) ● Service catalog in self-service mode ●Hybrid Cloud governance : consumption control ● ● Business users : In-apps process and rules engine : JBoss BRMS / BPMS ● Devs : Tooling for better collaboration (devops) : Openshift ● Ops : get to scale Standardized platform : controlled deployment profiles ●Multi-tenants platforms Openshift, Openstack, Satellite ● RHEL AND CONTAINER SECURITY OVERVIEW

Software Quality Mitigating risks on software is inherent in Open source community Development ● At Red Hat , we add : Q&A Build processes Cryptographic signatures Signed Protected access (ssl) Security teams Maintain for 10 years a stable and secure baseline (backporting) ● Makes RH a trusted supplier to customers RHEL AND CONTAINER SECURITY OVERVIEW

Certifications Business regulations Government FIPS-140-2 ( cryptographic implement properly) USGV6 (DoD IPV6 requirements) ●DISA STIG (Secure Technical implementation Guidelines) ●FISMA (Federal Information Security Management Act) ●FedRAMP (variant of FISMA process for cloud providers) ●US Army certificate of Networthiness ●USGCB : US government Configuration Baseline ● ● Finance PCI DSS 3.0 SOX 404 ● ● RHEL AND CONTAINER SECURITY OVERVIEW Technical regulations SCAP : Secure Content Automation Protocol (configuration requirements) OVAL : Open Vulnerability and Assessment Language : to describe vulnerabilities (founded by RH in 2002) CVE : common Vulnerability Enumeration : common identifier for common flaws IAVAs : (Information Assurance Vulnerability Alerts) similar to CVE for DOD personnel Common Criteria : up to EAL 4+ PCI DSS v3 : eg : Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.* SOX 404 :eg : Patch and configuration management to ensure that financial data is protected and that there is an audit trail to documenting all changes

Red Hat Security team ● ● ● ● ● ● ● ● Monitoring vulnerabilities, exploits & threats Triage Escalation and troubleshooting through lifecycle Communication with other affected vendors Internal communication, documentation, advisory Responsible for errata release Metrics and feedback to engineering Single point of contact for customers RHEL AND CONTAINER SECURITY OVERVIEW

EXCEPTIONAL SECURITY % of all critical security issues in Red Hat Enterprise Linux are fixed within… 6 1 RHEL AND CONTAINER SECURITY OVERVIEW day.

CONTAINERS

LINUX IS CONTAINERS CONTAINERS ARE LINUX CONTAINERS RHEL HOST Server Operating Environment KERNEL PHYSICAL RHEL AND CONTAINER SECURITY OVERVIEW ● Next-generation application platform for existing and new apps ● Portable across the hybrid cloud ● Container companies must be Linux companies DEVICE SUPPORT VIRTUAL SYSTEMD SELINUX PRIVATE NAMESPACE CGROUPS PUBLIC 63

Evolution: Traditional Enterprise OS Traditional application deployment TRADITIONAL ● ● ● ● ● ● APP A APP B APP C BINS/LIBS OS & SHARED SERVICES HARDWARE RHEL AND CONTAINER SECURITY OVERVIEW ● Single userspace runtime shared between applications. Environment and life cycle defined by host OS. Trend to isolate apps on hardware level. Managed by IT, very limited delegation. Stable, long maintenance, few updates, hardware-centric. Very limited flexibility. Resources generally underutilized. New project Application dependency Application rollout Security Fix OS Version Update

Evolution: Virtualization & IaaS INFRASTRUCTURE AS A SERVICE (IAAS) Application deployment via virt & IaaS ● APP A APP A APP B ● ● BINS/ LIBS BINS/ LIBS BINS/ LIBS ● ● GUEST OS GUEST OS GUEST OS HYPERVISOR HOST OS SERVER RHEL AND CONTAINER SECURITY OVERVIEW ● Application isolation per VM. Guest environment and lifecycle defined by application. Application and runtime abstracted from hardware. Higher flexibility at cost of increased redundancy and overhead. Complex multi-level management of host and VM layers Delegation along the Host / VM boundary. New project Application dependency Application rollout Security Fix OS Version Update

Evolution: Application-Centric IT Application-Centric IT & PaaS App delivery using Docker containers ● ● APP D APP C APP B APP A APP A ● ● BINS / LIBS BINS / LIBS BINS / LIBS BINS / LIBS BINS / LIBS HOST OS, SHARED SERVICES HARDWARE, VIRT, CLOUD RHEL AND CONTAINER SECURITY OVERVIEW ● Application packaged with individual runtime stack using Docker and deployed into containers. Multi-instance, multi-version, maximal flexibility, minimal overhead. Delegation along the container boundaries. Shared services provided by host / container environment. Standardized hardened container host, clustering, orchestration. New project Application dependency Application rollout Security Fix OS Version Update

Containers vs. Virt? APP B APP C APP D RHEL AND CONTAINER SECURITY OVERVIEW APP A ● APP A Generally complementary concepts ● Virtualization: vertical abstraction ● Containerization: horizontal segmentation ● Containers used to replace virtualization where container paradigms more applicable: ● Horizontal application isolation ● Lightweight delegation ● “Application Virtualization” ● Density ● Containers on top of Virt/Cloud common. Containerization BINS / LIBS BINS / LIBS BINS / LIBS BINS / LIBS BINS / LIBS Docker HOST OS, SHARED SERVICES Namespace Virtualization SELinux CGroups Virt Hypervisor HARDWARE s

Tech Details – Containers & Docker Linux Containers are a combination of kernel features: namespaces SELinux control groups ● Containers provide lightweight isolation of process, network, filesystem spaces. ● Docker builds on Linux Containers, adds an API, an image format and a delivery and sharing model. ● APP A APP A BINS/ LIBS BINS / LIBS Docker HOST OS, SHARED SERVICES Namespace SELinux CGroups s HARDWARE, VIRT, CLOUD RHEL AND CONTAINER SECURITY OVERVIEW

Key elements of Linux Containers ● Process Isolation ○ kernel namespace ● Security ○ SElinux ● Resource Management ○ cgroups ● Container Management ○ Docker RHEL AND CONTAINER SECURITY OVERVIEW

Process Isolation - Namespaces ● ● ● ● Namespaces isolates and limits the visibility that processes have of system resources Create a new environment with a subset of the resources Once set up, namespaces are transparent for processes Can be used in custom and complex scenarios RHEL AND CONTAINER SECURITY OVERVIEW

Process Isolation - Namespaces Namespaces Mount PID (process ID) Functionality Isolate the set of FS mount points seen by processes Process can have same PID in different NS (include PID1) Network Isolate the networking stack: ip addr, routes, netfilter iptable rules UTS Set a different host and domain names for NS Private inter-process communication environment: message queues, semaphores, shared memory IPC RHEL AND CONTAINER SECURITY OVERVIEW What does it mean? /tmp in container can be different in ns’ Remount ‘/’ read only within namespace Process in NS can’t see/interact with process outside All processes are visable in ‘root’ PID NS Each NS has its own private loopback IF Commonly used with virtual ethernet IF pair No impact to the rest of the system Useful when combined with Network NS Resources are only accessible within the Namespace

SELinux • Where did it come from? • Created by the United States National Security Agency (NSA) as set of patches to the Linux kernel using Linux Security Modules (LSM) • Released by the NSA under the GNU General Public License (GPL) in 2000 • Adopted by the upstream Linux kernel in 2003 RHEL AND CONTAINER SECURITY OVERVIEW

Discretionary Access Control (DAC) • Historically, Linux and Unix systems have used discretionary access control. • Ownership (user, group, and other) plus permissions. • Users have the ability (discretion) to change permissions on their own files. A user can chmod +rwx his or her home directory, and nothing will stop them. Nothing will prevent other users or processes from accessing the contents of his home directory. • Traditionally, the root user is omnipotent RHEL AND CONTAINER SECURITY OVERVIEW

Mandatory Access Control (MAC) • On a mandatory access control system, there is policy which is administratively set and fixed. • Even if you change the DAC settings on your home directory, if there is a policy in place which prevents another user or process from accessing it, you’re generally safe. RHEL AND CONTAINER SECURITY OVERVIEW

DAC vs. MAC RHEL AND CONTAINER SECURITY OVERVIEW

So How Does SELinux Work? • Everything is labelled • Files, processes, ports, etc., are all labeled with an SELinux context. • For files and directories, these labels are stored as extended attributes on the filesystem. • For processes, ports, etc., the kernel manages these labels. • SELinux policies define what is allowed • What is not allowed is denied RHEL AND CONTAINER SECURITY OVERVIEW

Strong Resource Control with CGroups RHEL AND CONTAINER SECURITY OVERVIEW

Resources managed by cgroups cpuset cpuacct cpu freezer blkio devices RHEL AND CONTAINER SECURITY OVERVIEW CPU Memory Storage Network memory hugetlb net_cls

Control Groups When using cgroups, resources are placed in controllers representing the type of resource; for example, cpu for CPU time, memory for memory usage, and blkio for disk I/O. Cgroups can contain multiple controllers. A cgroup is then split into slices, like a pie chart. RHEL AND CONTAINER SECURITY OVERVIEW

Introduction to SCAP Shawn Wells

Everyone knows that SCAP is a suite of XML standards for creating automated checklists for configuration and vulnerability scans! 8 1 OPENSHIFT TECHNICAL OVERVIEW

SCAP 8 2 OPENSHIFT TECHNICAL OVERVIEW HTML

8 3 SCAP HTML OpenSCAP Firefox OPENSHIFT TECHNICAL OVERVIEW

8 4 OPENSHIFT TECHNICAL OVERVIEW

GUIDANCE 8 5 OPENSHIFT TECHNICAL OVERVIEW

GUIDANCE VERIFICATION 8 6 OPENSHIFT TECHNICAL OVERVIEW

GUIDANCE VERIFICATION REMEDIATION 8 7 OPENSHIFT TECHNICAL OVERVIEW

GUIDANCE VERIFICATION REMEDIATION 8 8 OPENSHIFT TECHNICAL OVERVIEW XCCDF

GUIDANCE XCCDF VERIFICATION OVAL REMEDIATION 8 9 OPENSHIFT TECHNICAL OVERVIEW

9 0 GUIDANCE XCCDF VERIFICATION OVAL REMEDIATION <fix> scripts OPENSHIFT TECHNICAL OVERVIEW (ansible, bash…)

9 1 OPENSHIFT TECHNICAL OVERVIEW

Java Source Code to Hardened Container Image Khary Mendez

Current Pipeline Source Code to Live Container 9 3

EAP Hardening Dockerfile ● called from new image build ● specifies baseline image to extend ● executes custom commands 9 4 Shell Script ● called from Dockerfile ● executes command line actions (i.e. file editing) JBoss CLI Script ● called from shell script ● executes JBoss configuration changes

Demo

Source 2 Image Walk Through Code Developers can leverage existing development tools and then access the OpenShift Web, CLI or IDE interfaces to create new application services and push source code via GIT. OpenShift can also accept binary deployments or be fully integrated with a customer’s existing CI/CD environment.

Source 2 Image Walk Through Build OpenShift automates the Docker image build process with Sourceto-Image (S2I). S2I combines source code with a corresponding Builder image from the integrated Docker registry. Builds can also be triggered manually or automatically by setting a Git webhook. Add in Build pipelines Container Image Registry

Source 2 Image Walk Through Deploy OpenShift automates the deployment of application containers across multiple Node hosts via the Kubernetes scheduler. Users can automatically trigger deployments on application changes and do rollbacks, configure A/B deployments & other custom deployment types. Container Image Registry

Continuous Integration and Continuous Delivery Pipeline Khary Mendez

Day in The Life of a Developer (Old Way) 1 0

Day in The Life of a Developer (Old Way) 1 0

Day in The Life of a Developer (Old Way) 1 0

Business Problems Due to constraints, environments aren’t identical and the software is brittle. ● ● ● ● Cost - Issues are expensive to fix Security- Often left to the end Administrative - Overhead in provisioning environments People / Skillset - Reliance on key people

The New Way

The New Way

The New Way

Demo CI/CD Pipeline Developers 1 0 Test Management

Demo Scenario ● ● ● ● ● ● Developer pushes code change into the Git repository (GOGS) A security vulnerability is found in the code Developer fixes code A CVE is detected in the EAP image Image is updated Pipeline succeeds, updated code is deployed, then promoted to test

Scheduling OSCAP Scans Cameron wyatt

Open Control to Automate Security Authorization Package Shawn Wells

CAN YOU EXPLAIN YOUR ENTIRE ATO PROCESS? 1 1 OPENSHIFT TECHNICAL OVERVIEW

Thank You