IRS Mini Summit on OpenShift Security
A presentation at IRS Mini Summit on OpenShift Security in in Herndon, VA 20170, USA by Shawn Wells
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
With several co-presenters, and sponsored by the IRS, this session delivered an overview of the OpenShift architecture, IRS’ DevOps vision, RHEL and Container Security, OpenSCAP, OpenShift S2I (Source-to-Image), Atomic Scan, and how to use OpenControl to automated security authorization packages.
