OSD
OpenShift Network Calculator
Overview
The OpenShift Network Calculator helps you determine the network requirements for your OpenShift cluster, specifically designed for clusters using the OVN-Kubernetes Container Network Interface (CNI). This tool calculates the number of pods, services, and nodes your network configuration can support, and identifies potential network conflicts with OVN-Kubernetes reserved networks.
Proper network planning is critical when deploying OpenShift clusters, as incorrect CIDR ranges can lead to IP address exhaustion, network conflicts, or connectivity issues. This calculator is particularly useful when planning deployments for:
Add an Ingress Controller to an OSD GCP Cluster and optionally with a custom domain.
Starting with OpenShift 4.14, OSD GCP supports adding additional Ingress Controllers which can use used to configure a custom domain on a OSD GCP cluster without having to use the now deprecated Custom Domain Operator. This guide shows how to add an additional Ingress Controller ( public or private ) to a OSD GCP cluster and optionally also configuring a custom domain.
Prerequisites
- A Red Hat OpenShift Dedicated on GCP (OSD GCP) cluster, version 4.14 or above
- The oc CLI #logged in.
Set up environment
- Export few environment variables
Important: The variables below can be customized to fit your needs for your ingress controller.
Limit Egress with Google Secure Web Proxy
In this guide, we will implement egress restrictions for OpenShift Dedicated by using Google’s Secure Web Proxy . Secure Web Proxy is a cloud first service that helps you secure egress web traffic (HTTP/S). OpenShift Dedicated relies on egress being allowed to specific fully qualified domain names (FQDNs), not just IP addresses. Secure Web Proxy provides support for limiting egress web traffic to the FQDNs necessary for the external endpoints that OpenShift Dedicated relies on.
Maximo Application Suite on OpenShift Dedicated Google Cloud Platform ( OSD GCP )
IBM Maximo Application Suite (MAS) is a set of applications for asset monitoring, management, predictive maintenance and reliability planning. When combined with Red Hat OpenShift Dedicated on Google Cloud ( OSD GCP ), this frees up your Maximo and operations team to focus on what is important to them ( Maximo ) rather than having to worry about managing and building clusters.
This document outlines how to get quickly get started with OSD GCP and installing Maximo all through automation.
Limit Egress with Google Cloud NGFW Standard
In this guide, we will implement egress restrictions for OpenShift Dedicated by using Google’s Cloud Next Generation Firewall (NGFW) Standard . Cloud NGFW is a fully distributed firewall service that allows fully qualified domain name (FQDN) objects in firewall policy rules. This is necessary for many of the external endpoints that OpenShift Dedicated relies on.
Configure Network Policies and Egress Firewalls for a ROSA Cluster
It’s common to want to restrict network access between namespaces, as well as restricting where traffic can go outside of the cluster. OpenShift achieves this with the Network Policy and Egress Firewall resources.
It’s common to use these methods to restrict network traffic alongside Egress IP and other OpenShift and OVN-Kubernetes resources.
Prerequisites
- ROSA Cluster 4.14
- openshift-cli (
oc)- rosa-cli (
rosa)- jq
Project Template
The first thing to do is create a Project Template that containes Network Policys and Egress Firewalls with default deny rules
Patch token-refresher to use a cluster proxy
Currently, if you deploy a ROSA or OSD cluster with a proxy, the token-refresher pod in the openshift-monitoring namespace will be in crashloopbackoff. There is an RFE open to resolve this, but until then this can affect the ability of the cluster to report telemetry and potentially update. This article provides a workaround on how to patch the token-refresher deployment until that RFE has been fixed using the patch-operator.
Prerequisites
A logged in user with
cluster-adminrights to a ROSA or OSD Cluster deployed using a cluster wide proxyAssign Consistent Egress IP for External Traffic
It may be desirable to assign a consistent IP address for traffic that leaves the cluster when configuring items such as security groups or other sorts of security controls which require an IP-based configuration. By default, Kubernetes via the OVN-Kubernetes CNI will assign random IP addresses from a pool which will make configuring security lockdowns unpredictable or unnecessarily open. This guide shows you how to configure a set of predictable IP addresses for egress cluster traffic to meet common security standards and guidance and other potential use cases.
Configure Microsoft Entra ID as an OIDC identity provider for ROSA/OSD
This guide demonstrates how to configure Azure AD as the cluster identity provider in Red Hat OpenShift Service on AWS (ROSA). This guide will walk through the creation of an Azure Active Directory (Azure AD) application and configure Red Hat OpenShift Service on AWS (ROSA) to authenticate using Azure AD.
This guide will walk through the following steps:
- Register a new application in Azure AD for authentication.
- Configure the application registration in Azure AD to include optional and group claims in tokens.
- Configure the OpenShift cluster to use Azure AD as the identity provider.
- Grant additional permissions to individual groups.
Before you Begin
Create a set of security groups and assign users by following the Microsoft documentation .
OSD on Google Cloud
Stop default router from serving custom domain routes
Note: This page is only valid for clusters using the Custom Domain Operator (CDO), which are ROSA clusters prior to version 4.14
OSD and ROSA supports custom domain operator to serve application custom domain, which provisions openshift ingress controller and cloud load balancers. However, when a route with custom domain is created, both default router and custom domain router serve routes. This article describes how to use route labels to stop default router from serving custom domain routes.
Creating a OSD in GCP with Existing VPCs
Tip The official documentation for installing a OSD cluster in GCP can be found here .
For deploy an OSD cluster in GCP using existing Virtual Private Cloud (VPC) you need to implement some prerequisites that you must create before starting the OpenShift Dedicated installation though the OCM.
Prerequisites
NOTE: Also the GCloud Shell can be used, and have the gcloud cli among other tools preinstalled.
Create Filestore Storage for OSD in GCP
By default, within OSD in GCP only the GCE-PD StorageClass is available in the cluster. With this StorageClass, only ReadWriteOnce mode is permitted, and the gcePersistentDisks can only be mounted by a single consumer in read-write mode .
Deploying 3scale API Management to ROSA and OSD
This document will take you through deploying 3scale in any OSD or ROSA cluster. Review the official documentation here for more information or how to further customize or use 3scale.
Prerequisites
- An existing ROSA or OSD cluster
- Access to an AWS account with permissions to create S3 buckets, IAM users, and IAM policies
- A subscription for 3scale API Management
- A wildcard domain configured with a CNAME to your cluster’s ingress controller
Prepare AWS Account
Set environment variables (ensuring you update the variables appropriately!)
Configuring IDP for ROSA, OSD and ARO
Red Hat OpenShift on AWS (ROSA) and OpenShift Dedicated (OSD) provide a simple way for the cluster administrator to configure one or more identity providers for their cluster[s] via the OpenShift Cluster Manager (OCM) , while Azure Red Hat OpenShift relies on the internal cluster authentication operator .
The identity providers available for use are:
Installing the HashiCorp Vault Secret CSI Driver
The HashiCorp Vault Secret CSI Driver allows you to access secrets stored in HashiCorp Vault as Kubernetes Volumes.
Prerequisites
- An OpenShift Cluster (ROSA, ARO, OSD, and OCP 4.x all work)
- oc
- helm v3
Installing the Kubernetes Secret Store CSI
Create an OpenShift Project to deploy the CSI into
Set SecurityContextConstraints to allow the CSI driver to run (otherwise the DaemonSet will not be able to create Pods)
Installing the Kubernetes Secret Store CSI on OpenShift
The Kubernetes Secret Store CSI is a storage driver that allows you to mount secrets from external secret management systems like HashiCorp Vault and AWS Secrets.
It comes in two parts, the Secret Store CSI, and a Secret provider driver. This document covers just the CSI itself.
Prerequisites
- An OpenShift Cluster (ROSA, ARO, OSD, and OCP 4.x all work)
- kubectl
- helm v3
Installing the Kubernetes Secret Store CSI
Create an OpenShift Project to deploy the CSI into
AWS ALB
Note: It is recommended that you use the Cloud Front based guide unless you absolutely must use an ALB based solution.
Here ’s a good overview of AWS LB types and what they support
Problem Statement
Operator requires WAF (Web Application Firewall) in front of their workloads running on OpenShift (ROSA)
Operator does not want WAF running on OpenShift to ensure that OCP resources do not experience Denial of Service through handling the WAF
Examples of using a WAF in front of ROSA / OSD on AWS / OCP on AWS
Problem Statement
Operator requires WAF (Web Application Firewall) in front of their workloads running on OpenShift (ROSA)
Operator does not want WAF running on OpenShift to ensure that OCP resources do not experience Denial of Service through handling the WAF
Quick Introduction by Paul Czarkowski & Ryan Niksch on YouTube
