WIXLIB

participate in the software-defined network, for separation of function, the OpenShift Master should NOTbe scheduled to run application instances (pods). The following are the four functions of the OpenShiftMaster:API and Authentication – The Master provides the single API that all tooling and systems interactwith. Everything that interacts with OpenShift must go through this API. All API requests are SSLencrypted and must be authenticated. Authorizations are handled by fine-grained role-basedaccess control (RBAC). It is recommended to tie the Master to an external identity and accessmanagement system using LDAP, OAuth, or other providers. The Master evaluates requests forboth authentication (AuthN) and authorization (AuthZ). Users of OpenShift who have been grantedaccess can be authorized to work with specific projects.Desired and Current State – The state of OpenShift is held in the OpenShift data store. The datastore uses etcd, a distributed key-value store. The data store houses information about theOpenShift environment and pertaining to the OpenShift Master, including user account informationand the RBAC rules; the OpenShift environment state, including application environmentinformation and non-application user data; and important environment variables, secrets data, andother information.Scheduler – The scheduler determines pod placement within OpenShift. It uses a combination ofconfiguration and environment state (CPU, memory, and other environmental factors) to determinethe best fit for running pods across the Nodes in the environment. The scheduler is configured witha simple JSON file in combination with Node labels to carve up OpenShift. This allows placementof pods within OpenShift to be based on the real-world topology, making use of concepts such asregions, zones, or other constructs relevant to the enterprise. These factors can contribute to thescheduled placement of pods in the environment and can ensure that pods run on appropriateNodes associated with their function.Health and Scaling – The OpenShift Master is also responsible for monitoring the health of podsand scaling the pods as desired to handle additional load. The OpenShift Master executes livenessand readiness tests using probes that are defined by users. The OpenShift Master can detect failedpods and remediate failures as they occur.Service Layer – The OpenShift Service Layer allows for application components to easily communicatewith one another. For instance, a front-end web service containing multiple web servers would connect todatabase instances by communication via the database service. OpenShift automatically and transparentlyhandles load balancing across the services’ instances. In conjunction with probes, the OpenShift ServiceLayer ensures that traffic is only directed toward healthy pods, which helps to maintain componentavailability.Persistent Storage – Linux containers are natively ephemeral and only maintain data for as long as theyare running. Applications and/or application components may require access to a long-term persistentstorage repository, such as may be required for a database engine. OpenShift provides the means toconnect pods to external real-world storage, which allows for stateful applications to be used on theplatform. Persistent storage types that are usable include iSCSI, Fiber Channel, and NFS, as well as cloudtype storage and software-defined storage options such as Red Hat OpenShift Container Storage.Persistent storage can be dynamically provisioned upon the user’s request, provided the storage solutionhas an integration with OpenShift.OpenShift Router – The routing layer provides external access to applications hosted in OpenShift. Therouting layer operates in partnership with the Service Layer and provides automated load balancing to podsfor external clients. The OpenShift Router runs in pods on the platform but receives traffic from the outsideRed Hat OpenShift Container Platform Applicability Guide for ISO/IEC 27001:2013 White Paper6

world and proxies the traffic to the appropriate pods. The OpenShift Router uses the service endpointinformation to determine where to route and load balance traffic; however, it does not route traffic throughthe Service Layer.OpenShift SDN – The OpenShift software-defined network (SDN) is a unified cluster network that enablescommunication between pods across the OpenShift cluster. The OpenShift SDN configures an overlaynetwork that uses Open vSwitch (OVS). Red Hat currently provides three SDN plug-ins for use withOpenShift. The ovs-subnet plug-in provides a “flat” pod network where every pod can communicate withevery other pod and service cluster-wide. The ovs-multitenant plug-in provides project-level isolation forpods and services. Each project receives a unique Virtual Network ID (VNID) that identifies traffic from podsassigned to the project. Pods from different projects cannot send packets to or receive packets from podsand services of a different project by default. Administrators of OpenShift can join or isolate projects asrequired. Lastly, the ovs-networkpolicy plug-in provides extremely fine-grained access control via userdefined rules. Network policy rules can be built in a “mandatory access control” style, where all traffic isdenied by default unless a rule explicitly exists, even for pods/containers on the same host.OpenShift Registry – The OpenShift Registry provides integrated storage and management for sharingcontainer images, but OpenShift can utilize existing OCI-compliant container registries that are accessibleto the Nodes and the OpenShift Master via the network.Figure 2 is a high-level illustration of the OpenShift components.Figure 2: High-Level OpenShift ArchitectureUsers – User (operators, developers, application administrators) access to OpenShift is provided throughstandard interfaces including the Web UI, CLI, and IDEs. These interfaces go through the authenticatedand RBAC-controlled API. Users do not require system-level access to any of the OpenShift hosts, evenfor complicated application debugging and troubleshooting tasks.There are three types of users that can exist in an OpenShift environment: regular users, system users,and service accounts.Red Hat OpenShift Container Platform Applicability Guide for ISO/IEC 27001:2013 White Paper7

Regular users are created automatically in the system upon first logon or via the API. Mostinteractive OpenShift users, including operators, developers, and application administrators, will berepresented by this type of user account.System users This is the system:admin account which is a regular user type of account withelevated privileges. The system:admin account is the cluster administrator account that getscreated when the system is setup for the first time. This account has special privileges and canonly be logged on via a certificate from the console of the OpenShift Master.Service accounts are non-human system users, often associated with projects, used for APIaccess in automation situations. Some default service accounts are created and associated whena project is first created. Project and cluster administrators can create additional service accountsfor defining access to the contents of each project.Projects – A project is a Kubernetes namespace with additional OpenShift annotations and metadata. It isthe central vehicle by which access to resources for regular users is managed and is essentially the tenancymodel of OpenShift and Kubernetes. A project allows a community of users to organize and manage theircontent in isolation from other communities.For more information on OpenShift concepts, features, and functions, please refer to Red Hat’s productdocumentation.O P E N S H I F T C O N T AI N E R P L AT F O R M S E C U R I T YOpenShift enables continuous security with a defense-in-depth and secure software supply chain to theapplication platform. Security controls can be applied dynamically to the platform and the applications theplatform supports. This allows security controls to keep up with the scale and agility of applications deployedin the platform. OpenShift runs on Red Hat Enterprise Linux and makes heavy use of the existing securityfeatures built into the OS. Red Hat manages the OS packages and provides trusted distribution of content.Red Hat is committed to responsive action to security vulnerabilities. The security of OpenShift includesand utilizes hardened technologies such as SELinux; process, network, and storage separation; proactivemonitoring of capacity limits (CPU, disk, memory, etc.); and encrypted communications for infrastructuresupport including SSH, SSL, etc. Additionally, OpenShift provides integration with third-party identitymanagement solutions to support secure authentication and authorization options in alignment withorganization compliance requirements.The following is a high-level list of OpenShift security features and capabilities.Container Host and Platform Multitenancy – Red Hat Enterprise Linux can manage multitenancy for thecontainer runtime by using Linux namespaces, SELinux, CGroups, and Secure Computing Mode(seccomp) to isolate and protect containers, which can be useful for maintaining separation for workloadsof differing classifications.Container Content – The Red Hat Container Catalog delivers validated application content from Red Hatand certified ISV partners.Container Registries – OpenShift includes an integrated container registry that provides basic functionalitysupporting build and deployment automation within the cluster, tied into the OpenShift RBAC. Within thecontext of an organization needing to adhere to FISMA Moderate requirements, Red Hat Quay is anadditional product that provides a registry with capabilities for both RBAC and vulnerability scanning ofapplications and software in images and more.Red Hat OpenShift Container Platform Applicability Guide for ISO/IEC 27001:2013 White Paper8

Building Containers – OpenShift integrates tightly with Jenkins and can be easily integrated with otherContinuous Integration/Continuous Delivery (CI/CD) tools to manage builds, code inspection, codescanning, and validation.Deploying Containers – By default, OpenShift prevents containers from running as root or otherspecifically-named users. In addition, OpenShift enables granular deployment policies that allowoperations, security, and compliance teams to enforce quotas, isolation, and access protections.Container Orchestration – OpenShift integrates secure operational capabilities to support trust betweenusers, applications, and security policies.Network Isolation – OpenShift uses a SDN approach to provide a unified cluster network that enablescommunication between pods across the OpenShift cluster. The pod network is established and maintainedby the OpenShift SDN plug-ins, which create an overlay network using OVS. There are three SDN plug-insavailable from Red Hat as options for the customer to deploy: the ovs-subnet, ovs-multi-tenant, and ovsnetworkpolicy. Other third-party SDN solutions exist that are capable of being integrated into OpenShift.Secure the data – OpenShift provides access to and integration with a broad range of storage platformsand protocols, allowing applications to securely store and encrypt application data.API management – OpenShift can be integrated with the 3scale API Management platform to authenticate,secure, and rate-limit API access to applications and services.SCOPE AND AP PRO ACH F OR REVIEWThe understanding of OpenShift and Red Hat Enterprise Linux and their combined capabilities was gainedthrough product specification, installation, configuration, administration, and integration documentationprovided by Red Hat and generally made available from Red Hat’s public-facing web site. Coalfire furtherconducted interviews and engaged in live product demonstrations with Red Hat personnel. For live productdemonstration purposes, OpenShift was also implemented on Red Hat Enterprise Linux in a labenvironment to provide hands-on testing and analysis of the system’s capabilities to support compliance.Coalfire’s review of OpenShift on Red Hat Enterprise Linux began with a general alignment of theapplicability of the technology against the high-level ISO/IEC 27001:2013 ISMS requirements with guidancefor the requirements provided by ISO/IEC 27002:2013. This was further narrowed down to specificrequirements that may be considered applicable to a secure operation of OpenShift. An analysis ofcapability for the reviewed technology to address the applicable requirements was then conducted. Coalfireconsidered inherent capability of OpenShift to enable security controls for the protection of supportedworkloads and data. Where inherent capabilties did not exist by design, consideration was made for theintegration of recommended adjacent people, processes, and other technologies to support the controlrequirements.S C O P E O F T E C H N O L O G Y AN D S E C U R I T Y S T AN D A R D T O R E V I E WCoalfire was tasked by Red Hat to review OpenShift as deployed on Red Hat Enterprise Linux. The primaryfocus of the review included the components, features, and functionality of OpenShift along with thesupporting underlying OS features and functionality when the components are deployed on Red HatEnterprise Linux. Coalfire did not include in this assessment the pods or containers (workloads) that anorganization (Red Hat’s customers) may deploy in OpenShift. Containers that were deployed in the labenvironment were strictly used for the purposes of demonstrating the platform’s orchestration, deployment,and management capabilities. Furthermore, Coalfire did not assess available public or private imageRed Hat OpenShift Container Platform Applicability Guide for ISO/IEC 27001:2013 White Paper9

registries or repositories that may be used for acquiring application code, services, dependencies, or otherelements to be hosted on or used within OpenShift.For this review, Coalfire included requirements from ISO/IEC 27001:2013 Information technology – Securitytechniques – Information security management systems – Requirements Second Edition, October 1, 2013publication available from www.iso.org. For broader understanding of the ISO/IEC 27001:2013requirements, Coalfire referenced the ISO/IEC 27002:2013 Information technology – Security techniques Code of practice for information security controls and CFISO as a certification body.C O AL F I R E E V AL U AT I O N M E T H O D O L O G YCoalfire initially examined the ISO/IEC 27001:2013 requirements and identified them as either procedural(organizational) or technical (implementation). Qualification of a requirement as procedural or technical wasbased on a review of the requirement narrative, testing procedures, and guidance.“Non-technical” procedural requirements that include definition and documentation of policies, procedures,and standards were not considered directly applicable to the technical capabilities of the solution thoughshould have bearing on the management and use of the solution. Likewise, “non-technical” requirementsincluding operational procedures that describe manual processes were not assessed against thetechnology’s capability. Examples of this type of “non-technical” requirement included maintenance offacility visitor logs, verification of an individual’s identity prior to granting physical or logical access,performance of periodic physical asset inventories, or generation of network topology or flow diagrams.Technical requirements were then assessed to determine applicability to the capabilities of the solutionand/or solution components to enable supporting controls. Where achievement of the requirementobjectives was more likely to be met using an external and non-adjacent mechanism, the requirement wasdetermined to be “not applicable” to the assessed technology. Examples of requirements that Coalfiredetermined to be “not applicable” to OpenShift on Red Hat Enterprise Linux included the use of encryptionkey management, wireless networking, technical physical access controls, and antivirus solutions. That isnot to say that these are not important factors to consider as it pertains to OpenShift, but rather thatOpenShift does not natively or inherently provide these capabilities to the extent necessary to achievecompliance.Where the requirement was qualified as applicable, Coalfire further assessed the capability of the solutionto address or enable controls in support of meeting the requirement objectives.Each applicable requirement is described in the table in the following section. This table includes thefindings of applicability along with a short narrative describing the capability.OPENSHIFT AP PLIC ABIL ITY TO ISO/IEC 27001:2013The following table details the applicability of OpenShift providing control enablement through either defaultor configurable implementation. ISO/IEC 27001:2013 requirements that are not listed in the following tablewere determined to be not applicable to capabilities of the reviewed technology to address. Everyrequirement of ISO/IEC 27001:2013 must be addressed by the organization seeking certification. Allrequirements are the responsibility of that organization, including how controls are enabled or configuredto meet those requirements. The enablement of technical controls is highly dependent on the knowledgeand application of people and processes to ensure proper operation of controls in alignment with supportedrequirements.Red Hat OpenShift Container Platform Applicability Guide for ISO/IEC 27001:2013 White Paper10

REQUIREMENTTITLEREQUIREMENTDESCRIPTIONCONTROL CAPABILITY SUMMARYA.9.1.2 Access tonetworks and networkservicesUsers shall onl

Red Hat OpenShift Container Platform Applicability Guide for ISO/IEC 27001:2013 White Paper 5 The following is a list of components and roles that support OpenShift. Operating System (OS) - OpenShift can be deployed on either Red Hat Enterprise Linux or, soon, Red Hat CoreOS. Red Hat CoreOS is a container- and Kubernetes-optimized, minimal footprint OS powered by much of the