Skip to content

OpenShift Container Platform

  1. OpenShift
  2. OpenShift Streaming and Training
  3. OpenShift on Public Cloud
    1. Azure Red Hat OpenShift ARO
  4. Blogs
  5. Meetings
  6. Differences in developing on OpenShift as opposed to other Kubernetes distributions
  7. Red Hat’s approach to Kubernetes. Standardization
  8. OpenShift.io online IDE
  9. OC CLI Auto Completion
  10. Cluster Autoscaler in OpenShift
  11. e-Books
    1. Kubernetes e-Books
  12. Online Learning
  13. Local Installers
  14. Cloud Native Development Architecture. Architectural Diagrams
  15. Cluster Installers
    1. OKD 3
    2. OpenShift 3
    3. OpenShift 4
      1. OpenShift 4 deployment on VMWare vSphere
        1. Deploying OpenShift 4.4 to VMware vSphere 7
  16. Networking (OCP 3 and OCP 4)
  17. Security
    1. How is OpenShift Container Platform Secured?
    2. Security Context Constraints
      1. Review Security Context Constraints
    3. OpenShift Network Model & Network Policy
      1. Network Security Zones
      2. OpenShift Route and OpenShift Ingress
      3. OpenShift Egress
  18. Openshift Compliant Docker Images
    1. Gitlab
    2. Atlassian Confluence6
    3. Sonatype Nexus 3
    4. Rocket Chat
  19. IBM Cloud Paks and OpenShift
  20. OpenShift on AWS
  21. OpenShift Dedicated
  22. Other Awesome Lists

OpenShift

OpenShift Streaming and Training

OpenShift on Public Cloud

Azure Red Hat OpenShift ARO

Blogs

Meetings

Differences in developing on OpenShift as opposed to other Kubernetes distributions

Red Hat’s approach to Kubernetes. Standardization

Reference Author URL
“Given the difficulty of navigating the cloud-native ecosystem, especially the one around Kubernetes, there is a high demand for easy-to-administer development platforms that deliver applications in Kubernetes-managed containers.” OMDIA Red Hat’s approach to Kubernetes
Industry momentum has aligned behind Kubernetes as the orchestration platform for Linux® containers. Choosing Kubernetes means you’ll be running the de facto standard regardless of which cloud environments and providers are in your future. CNCF Survey 2019 Red Hat’s approach to Kubernetes
“It’s not just enough to do Kubernetes. You do need to do CI/CD. You need to use alerting. You need to understand how the security model of the cloud and your applications interplay.” Clayton Coleman,Senior Distinguished Engineer, Red Hat Red Hat’s approach to Kubernetes
“Kubernetes is scalable. It helps develop applications faster. It does hybrid and multicloud. These are not just technology buzzwords, they’re real, legitimate business problems.” Brian Gracely,Director, Product Strategy, Red Hat OpenShift Red Hat’s approach to Kubernetes
“Our job is to make it easier and easier to use, either from an ops point of view or a developer point of view—while acknowledging it is complex, because we’re solving a complex problem.” Chris Wright,Chief Technology Officer, Red Hat Red Hat’s approach to Kubernetes

rh openshift solutions 2020

OpenShift.io online IDE

  • openshift.io 🌟 an online IDE for building container-based apps, built for team collaboration.

OC CLI Auto Completion

Cluster Autoscaler in OpenShift

e-Books

Kubernetes e-Books

Online Learning

Local Installers

Cloud Native Development Architecture. Architectural Diagrams

Cloud-native development

Cloud-native development container runtimes


Cluster Installers

OKD 3

OpenShift 3

OpenShift 4

OpenShift 4 deployment on VMWare vSphere

Deploying OpenShift 4.4 to VMware vSphere 7

openshift 4 to vsphere 7

Networking (OCP 3 and OCP 4)

Security

How is OpenShift Container Platform Secured?

Security Context Constraints

Review Security Context Constraints

  • Security Context Constraints (SCCs) control what actions pods can perform and what resources they can access.
  • SCCs combine a set of security configurations into a single policy object that can be applied to pods. These security configurations include, but are not limited to, Linux Capabilities, Seccomp Profiles, User and Group ID Ranges, and types of mounts.
  • OpenShift ships with several SCCs. The most constrained is the restricted SCC, and the least constrained in the privileged SCC. The other SCCs provide intermediate levels of constraint for various use cases. The restricted SCC is granted to all authenticated users by default.
  • The default SCC for most pods should be the restricted SCC. If required, a cluster administrator may allow certain pods to run with different SCCs. Pods should be run with the most restrictive SCC possible.
  • Pods inherit their SCC from the Service Account used to run the pod. With the default project template, new projects get a Service Account named default that is used to run pods. This default service account is only granted the ability to run the restricted SCC.
  • Recommendations:
    • Use OpenShift’s Security Context Constraint feature, which has been contributed to Kubernetes as Pod Security Policies. PSPs are still beta in Kubernetes 1.10, 1.11, and 1.12.
    • Use the restricted SCC as the default
    • For pods that require additional access, use the SCC that grants the least amount of additional privileges or create a custom SCC Audit
    • To show all available SCCs: oc describe scc
    • To audit a single pod: oc describe pod <POD> | grep openshift.io\/scc
    • Remediation: Apply the SCC with the least privilege required

OpenShift Network Model & Network Policy

Network Security Zones

  • stackoverflow.com: Is that possible to deploy an openshift or kubernetes in DMZ zone? 🌟
  • OpenShift and Network Security Zones: Coexistence Approaches 🌟🌟🌟
    • Introduction: Kubernetes and consequently OpenShift adopt a flat Software Defined Network (SDN) model, which means that all pods in the SDN are in the same logical network. Traditional network implementations adopt a zoning model in which different networks or zones are dedicated to specific purposes, with very strict communication rules between each zone. When implementing OpenShift in organizations that are using network security zones, the two models may clash. In this article, we will analyze a few options for coexistence. But first, let’s understand the two network models a bit more in depth.
    • Network Zones have been the widely accepted approach for building security into a network architecture. The general idea is to create separate networks, each with a specific purpose. Each network contains devices with similar security profiles. Communications between networks is highly scrutinized and controlled by firewall rules (perimeter defense).
    • Conclusion: A company’s security organization must be involved when deciding how to deploy OpenShift with regard to traditional network zones. Depending on their level of comfort with new technologies you may have different options. If physical network separation is the only acceptable choice, you will have to build a cluster per network zone. If logical network type of separations can be considered, then there are ways to stretch a single OpenShift deployment across multiple network zones. This post presented a few technical approaches.

Network Security Zones

OpenShift Route and OpenShift Ingress

OpenShift Egress

Openshift Compliant Docker Images

Gitlab

Atlassian Confluence6

Sonatype Nexus 3

Rocket Chat

IBM Cloud Paks and OpenShift

  • cloudpak8s.io
  • What are IBM Cloud Paks? Beyond containers and Kubernetes, enterprises need to orchestrate their production topology, and to provide management, security and governance for their applications. They need to do this while improving efficiency and resiliency, reducing costs and maximizing ROI.
  • IBM Cloud® Paks are enterprise-ready, containerized software solutions that give clients an open, faster and more secure way to move core business applications to any cloud. Each IBM Cloud Pak® includes containerized IBM middleware and common software services for development and management, on top of a common integration layer — designed to reduce development time by up to 84 percent and operational expenses by up to 75 percent. IBM Cloud Paks run wherever Red Hat® OpenShift® runs and are optimized for productivity and performance on Red Hat OpenShift on IBM Cloud.
  • IBM Cloud Pak Playbook The Cloud Pak for Applications provides product offerings to support modernizing existing applications and building new cloud native applications. The applications run within a Kubernetes cluster provided with the Red Hat OpenShift Container Platform. The focus provided here is on running application workloads as containers. The Cloud Pak for Applications is a bundle of multiple offerings. This diagram provides an overview of what offerings are included and what they would be used for:

cp4a_overview

OpenShift on AWS

OpenShift Dedicated

Other Awesome Lists