Overview

The National Cyber Security Centre (NCSC) has outlined 14 Cloud Security Principles for organizations to follow when using cloud services. These principles cover protecting data, managing user access, implementing secure practices, and responding to incidents. The goal is to ensure that cloud services are used securely and in compliance with security policies.

The 14 cloud security principles identified by the UK (NCSC) are designed to help organizations choose a cloud provider that meets their security needs. These principles apply to both cloud platforms and to Software as a service (SaaS).

The document looks at Red Hat products and managed services, which can help address these principles. The current scope for this document is only for Red Hat OpenShift on AWS (ROSA) with links and reference to AWS policies where relevant.

Document limitations and legal construct

The information provided by Red Hat in this document intends to describe Red Hat’s approach to security and its security ecosystem. Contact your Red Hat representative if further detail or clarification is required. They will forward the request to the Red Hat Product Security team, who will respond with further direction or details for those parties that are entitled and require the next level of detail within an appropriate framework.
Red Hat has and will continue to maintain close liaison and collaboration with NCSC as we do with other key Government National Technical Authorities or International Standards boards to provide an enhanced awareness of our development controls and processes. Red Hat is confident that all statements within this document are within the spirit and the technical details of the regulatory document.
Note that the information provided in this document is for general awareness only, may be subject to change, and does not constitute legal or professional advice or warranty of any kind, including fitness for a particular purpose or compliance with any law or regulation.

NCSC Principles

Principle 1 - Data in transit protection

Data should be adequately protected against tampering and eavesdropping as it transits networks inside and external to the cloud.

Red Hat response
The main cloud service suppliers provide their own mechanisms for ensuring data is encrypted between external services. For example, AWS provides AWS PrivateLink, allowing customers to use the Transport Layer Security (TLS) protocol to protect data when traveling between the cloud services and end users.

Within Red Hat OpenShift, all communication channels with the REST API, as well as between master components and the API server, are secured by default with TLS v1.2. You can specify different TLS security profiles for each component such as v1.3 using the “Modern” profile. The OpenShift server and command line client provide TLS v1.2 or newer by default. Both server and client use modern cipher suites with authenticated encryption algorithms. Cipher suites with deprecated and insecure algorithms, such as RC4, 3DES, and MD5, are turned off by default.

Additionally, within the PCI DSS Report of Compliance (ROC) report, there are multiple references to TLS. As customers are responsible for their data, all references in the ROC for TLS speak to host-managed infrastructure.

Principle 2 - Asset protection and resilience

Data and the assets storing or processing it should be protected against physical tampering, loss, damage, or seizure.

Red Hat response
Red Hat OpenShift can be deployed on-premise in a private cloud, public cloud or hybrid mode, crossing multiple clouds. ROSA utilizes the underlying AWS storage and network utilities. OpenShift employs strong access controls to limit access to sensitive assets. This includes authentication mechanisms like usernames and passwords, multi-factor authentication (MFA), and integration with identity providers, for example, LDAP, and Active Directory. OpenShift supports the physical and logical segregation of clusters, data, and networks. The SOC 2 Type 2 attestation report for ROSA contains a 'Logical and Physical Access' section that speaks to this segregation.

Principle 3 - Separation between customers

A malicious or compromised customer of the service should not be able to access or affect the service or data of another.

Red Hat response
AWS logically segregates each customer’s data from other customers’ data reducing the possibility of cross-customer contamination. Within OpenShift, network,storage, and user configuration provides segregation within the platform. In addition to the section referenced in principle 2, the Report on Compliance (PCI DSS ROC) contains information about 'Network Segmentation.'

Principle 4 - Governance framework

The service provider should have a security governance framework that coordinates and directs its management of the service and information within it.

Red Hat response
Red Hat strives to produce resilient, high-quality software to meet a customer's business needs. To do so, we created a software development lifecycle approach, the Red Hat Secure Development Lifecycle (RH-SDL), which aligns with NIST SP 800-218, the Secure Software Development Framework (SSDF).

The main goal of RH-SDL is to formalize security controls that provide demonstrable evidence of adherence to internal security standards while following the structure of NIST SSDF and using controls outlined in NIST SP 800-53.

The aligned NIST set of controls implemented across the Red Hat portfolio includes but is not limited to, static and dynamic security scanning, threat modeling along with architecture and code reviews, penetration testing including automated scanning and white box assessments, dynamic code analysis, malware scanning, and producing a Software Bill of Materials (SBOMs).

By following these practices, Red Hat strives to protect its customers by reducing the number of vulnerabilities in released software, mitigating the potential impact of undetected or unaddressed vulnerabilities, and addressing the root causes of vulnerabilities to prevent future recurrences. Adherence to RH-SDL enhances security built into the design and architecture of a software product.

The Software Development Lifecycle is covered in the SOC 2 Type 2 report in the 'Change Management' section and in TSC Reference CC5.3.
Red Hat Product Security practices are aligned to OWASP and ISO12207:2017 wherever feasible.

Principle 5 - Operational security

The service needs to be operated and managed securely in order to impede, detect, or prevent attacks.

Red Hat response
Red Hat Site Reliability Engineers (SREs) maintain a centralized monitoring and alerting system for all managed service cluster components, the SRE services, and underlying CSP accounts.

Platform audit logs are securely forwarded to a centralized security information and event monitoring (SIEM) system, where they may trigger configured alerts to the SRE team and are subject to manual review. Audit logs are retained in the SIEM system for one year. Audit logs for a given cluster are not deleted at the time the cluster is deleted.

PCI DSS ROC references the period for retaining audit logs as part of Requirement 10.7. This is also covered in the SOC 2 Type 2 report under the 'System Operations' & 'Availability' sections.

Principle 6 - Personnel security

Where service provider personnel have access to your data and systems, you need a high degree of confidence in their trustworthiness and the technical measures in place.

Red Hat response
All Red Hat new hires are subject to Right to Work (RTW) checks to ensure they hold a legal right to work in the country where they are hired.

Red Hat site reliability engineers (SREs) are trained professionals who adopt the principle of “least privilege” when required to access customers' systems and utilize best practices throughout. Regarding Red Hat Support, members of the Red Hat Customer Experience and Engagement (CEE) team typically have read-only access to parts of the cluster. Specifically, CEE has limited access to the core and product namespaces and does not have access to the customer namespaces.

PCI DSS ROC documentation discusses screening of employees as part of Requirement 12.7.

NOTE: This is only for OSD SREs with privileged access to ROSA.

Principle 7 - Secure development

Cloud services should be designed, developed, and deployed in a way that minimizes and mitigates threats to their security.

Red Hat response
All Red Hat software comes from upstream and publicly available upstream projects. These projects use an assortment of methods and tools, such as Gitlab, to track changes. As projects are productized, the software is pulled into dedicated Red Hat build servers and is reviewed, tested, and packaged by authorized Red Hat employees. All packaged products are signed by Red Hat signing servers prior to release to Red Hat subscribers so that the authenticity of the packages can be verified.

We freeze a stable version of a code base. Then, we test it, remove bugs, and harden it for enterprise use. We know it will work after it has been benchmarked against enterprise and security requirements and a project becomes a product. We release a standardized version tailored for enterprise use.

The PCI DSS ROC report discusses secure development processes in Requirement 6.3.2.a.

Principle 8 - Supply chain security

The service provider should ensure that its supply chain meets the same security standards that the organization sets for itself.

Red Hat response
Red Hat Product Security helps ensure that Red Hat produces trustworthy, high-quality software that meets a customer's business needs. To do so, we created the Red Hat Secure Software Management Lifecycle (SSML), an SDLC approach that directly aligns with the NIST Secure Software Development Framework.

That framework articulates and aggregates commonly accepted and desired actions to effectively manage software by establishing a core set of secure software development practices. By following these practices, Red Hat reduces the number of vulnerabilities in released software, mitigates the potential impact of undetected or unaddressed vulnerabilities, and addresses the root causes of vulnerabilities to prevent future recurrences. Also, Red Hat Product Security practices are aligned to OWASP and ISO 12207:2017 wherever feasible.

Red Hat, during the performance of SSML, carries out scanning and testing for our source code. Red Hat processes include threat modeling and static and dynamic code analysis. Selected Red Hat software offerings may go through the Common Criteria and FIPS-140 review process, which provides additional structured testing of the offering’s core components. Structured testing includes automated testing, manual testing, testing of vulnerabilities from internal sources as well as penetration testing done by labs, and regression testing.

All issues found during scanning and testing are logged in the appropriate defect tracking system and are prioritized by product management with guidance from Red Hat Product Security. As our code is open source, customers can access the source code to conduct any validations.

Red Hat also has a Supply Chain team that guides and reviews all parts of the development, quality engineering, and release environments. Version control is maintained and signed.

Principle 9 - Secure user management

Your provider should make the tools available for you to securely manage your use of their service, preventing unauthorized access and alteration of your resources, applications, and data.

Red Hat response
For users to interact with the OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. The OpenShift Container Platform master includes a built-in OAuth server. Users obtain OAuth access tokens to authenticate themselves to the API. Additional identity providers can be configured such as htpasswd, keystone, LDAP, OpenID Connect, Github, and Gitlab.

The customer is responsible for administering their user management as defined in Roles and Responsibilities for their application and data.

The ROSA Docs documentation contains a useful authentication and authorization overview that covers the tools used to securely manage the service.

Principle 10 - Identity and authentication

All access to service interfaces should be constrained to a securely authenticated and authorized identity.

Red Hat response
Most access by Red Hat Site Reliability Engineering (SRE) teams is done by using cluster operators through automated configuration management.

SREs access Red Hat OpenShift clusters through the web console or command-line tools. Authentication requires multi-factor authentication (MFA) with industry-standard requirements for password complexity and account lockouts. SREs must authenticate as individuals to ensure auditability. All authentication attempts are logged to a Security Information and Event Management (SIEM) system. SREs access private clusters using an encrypted HTTP connection. Connections are permitted only from a secured Red Hat network using an IP allowlist or a private cloud provider link.

SRE adheres to the principle of least privilege when accessing Red Hat OpenShift clusters and their associated components.

Principle 11 - External interface protection

All external or less-trusted interfaces of the service should be identified and defended appropriately.

Red Hat response
Each managed cluster is protected by a secure network configuration using firewall rules for Security Groups. Additionally, ROSA customers are also protected against DDoS attacks with AWS Shield Standard.

Customers can optionally configure their managed cluster endpoints, such as web console, API, and application router, to be made private so that the cluster control plane and applications are not accessible from the Internet. Red Hat SREs still require Internet-accessible endpoints that are protected with IP allow-lists.

AWS customers can configure a private network connection to their cluster through technologies such as AWS VPC peering, AWS VPN, or AWS Direct Connect.

Principle 12 - Secure service administration

The design, implementation, and management of the cloud service provider’s administration systems should follow enterprise good practice, recognizing their high value to attackers.

Red Hat response
Red Hat achieves a wide range of cybersecurity validations and certifications for our products and services in global markets. Among these are some of the most well-known standards for information security management, safeguarding customer data, and cloud security.

Red Hat performs periodic penetration tests against OpenShift Service on AWS. Tests are performed by an independent internal team by using industry standard tools and best practices. Any issues that may be discovered are prioritized based on severity. Any issues found belonging to open source projects are shared with the community for resolution.

Red Hat follows industry best practices which is evidenced through the achievement of ISO 27001 certifications for ROSA, and Red Hat's Corporate ISMS.

Principle 13 - Audit information and alerting for customers

You should be able to identify security incidents and should have the information necessary to find out how and when they occurred.

Red Hat response
The Red Hat Product Security team guides our product teams in building our solutions backed by secure development practices and industry standards. The final phase of the secure development process focuses on incident response and the necessary steps Red Hat must take to remediate our products and supported services. As vulnerabilities are publicly posted and identified, the Red Hat Product Security Incident Response Team (PSIRT) quickly assesses and remediates these vulnerabilities to ensure our products are secured for our customers, their platforms, and ecosystems.

The PSIRT is the executive agent in coordinating vulnerability responses across all Red Hat offerings and follows the Red Hat Product Security Incident Response Plan (IRP). This plan alerts key internal stakeholders and assists in directing the required resources to be allocated for the correction, testing, and distribution of the fixes to our subscribers to resolve the vulnerability.

Principle 14 - Secure use of the service

Your cloud provider should make it easy for you to meet your data protection responsibilities. Services should be secure by design and by default.

Red Hat response
Red Hat defines and follows a data classification standard to determine the sensitivity of data and highlight the inherent risk to the confidentiality and integrity of that data while it is collected, used, transmitted, stored, and processed. Customer-owned data is classified at the highest level of sensitivity and handling requirements.

Red Hat OpenShift Managed Services uses the cloud provider Key Management Service (KMS) to help securely manage keys for encrypted data. These keys are used for control planes, infrastructure, and worker data volumes that are encrypted by default. Persistent volumes (PVs) for customer applications also use KMS for key management.

When a customer deletes their cluster, all cluster data is permanently deleted, including control plane data volumes and customer application data volumes, such as persistent volumes (PV).

Conclusion

Along with the built-in organizational and platform security, Red Hat also provides a Security Reference Architecture for ROSA. The Security Reference Architecture for ROSA is a set of guidelines for deploying Red Hat OpenShift on AWS clusters to support high-security production workloads that align with Red Hat and AWS best practices.

This overall architectural guidance compliments detailed, specific recommendations for AWS services and the Red Hat OpenShift Container Platform (OCP).

The Security Reference Architecture (SRA) for ROSA is a living document and is updated periodically based on new feature releases, customer feedback, and evolving security best practices.

ROSA has also attained certification for the following compliance standards:
ISO 27001: 2013
ISO 27017: 2015
ISO 27018: 2019
SOC 2 Type 2
PCI DSS
IRAP

In conclusion, this document has delved into the critical aspects of security within the Red Hat OpenShift environment on AWS, highlighting the robust measures and best practices to comply with the NCSC Cloud Security Principles. By aligning the powerful features of Red Hat OpenShift with the scalable infrastructure provided by AWS, organizations can establish a resilient and secure foundation for their cloud-native applications.