Managed OpenShift services

What “Managed OpenShift” Means

In a managed OpenShift service, the cloud or platform provider runs and operates the OpenShift control plane and most of the underlying infrastructure for you. You consume OpenShift as a service rather than installing and operating the cluster yourself.

Key characteristics:

• You do not:
• Install or upgrade OpenShift yourself
• Manage control plane nodes (API server, etcd, controllers)
• Patch or upgrade the underlying OS images of managed nodes
• You do:
• Create projects, deploy workloads, configure networking and storage within the constraints of the service
• Control worker node sizing and scaling (within the service model)
• Integrate with your cloud/network/security environment where supported

This contrasts with self-managed installation models (IPI/UPI) where you are fully responsible for the lifecycle of both the cluster and the underlying infrastructure.

Typical Managed OpenShift Offerings

Managed OpenShift offerings are usually delivered as cloud services. The naming and exact feature sets vary, but they have common patterns.

Common examples (names may differ slightly over time / by region):

• Red Hat OpenShift Dedicated (OSD)
• Runs on Red Hat-managed AWS or GCP accounts
• Red Hat operates the cluster; you consume OpenShift as a tenant
• Red Hat OpenShift Service on AWS (ROSA)
• Jointly delivered by Red Hat and AWS
• OpenShift is a first-class AWS service, integrated with AWS billing and IAM
• AWS hosts infrastructure; Red Hat manages OpenShift components
• Azure Red Hat OpenShift (ARO)
• Joint offering from Microsoft and Red Hat on Azure
• Deep integration with Azure networking, IAM, and marketplace/billing
• Other cloud/hosted variants
• Numerous providers host OpenShift as a service or offer it as a managed platform in private data centers or sovereign clouds.

While concrete details differ, the underlying principle is the same: you consume OpenShift as a managed platform with a shared responsibility model.

Shared Responsibility Model

Managed services do not eliminate responsibility; they redistribute it.

A typical division of responsibilities:

• Provider responsibilities
• OpenShift installation and initial configuration
• Lifecycle of control plane:
• API servers
• etcd
• Controller/Operator stack
• Control plane high availability and scaling (within SLAs)
• Cluster upgrades, security patches, and bug fixes for:
• OpenShift components
• Underlying OS images and base infrastructure components they control
• Default monitoring and logging at the platform level
• SRE-style operations and 24/7 support for cluster health
• Customer responsibilities
• Application deployment and configuration
• Namespaces/projects, quotas, and access control policies
• Security policies inside the cluster:
• RBAC roles and bindings
• NetworkPolicies for workloads
• Pod security settings within allowed constraints
• Data security and compliance:
• Encryption and backup of application data
• Retention policies and access control for logs/metrics you own
• Integrations:
• External identity providers (if allowed)
• External storage, messaging, databases, and other services
• Cost management via:
• Node sizing and autoscaling decisions
• Efficient workload placement and resource limits

Managed OpenShift services often publish explicit shared responsibility matrices; it is important to understand these for operational planning and audits.

Control Plane and Infrastructure Management

In managed OpenShift, the control plane is not something you log into or directly administer:

• You typically cannot:
• SSH into control plane nodes
• Change configuration of core control plane services directly
• Modify core Operators outside supported mechanisms
• You typically can:
• Request cluster-level changes using well-defined APIs or configuration resources (e.g., Infrastructure CRs, cluster settings exposed by the service)
• Change worker node pool parameters (instance type, autoscaling bounds) within quotas
• Use built-in Operators included and supported by the managed offering, sometimes with restricted configuration options

For many users, this is a benefit: less operational overhead and fewer ways to break the cluster. For advanced or specialized workloads, these restrictions can be a limitation and need to be considered early.

Cluster Provisioning Workflow in Managed Services

Although details vary by provider, most managed OpenShift services follow a similar high-level workflow:

1. Cluster request / creation
• You use:
• A cloud provider console or marketplace UI, or
• A CLI (rosa, az aro, or provider-specific tooling), or
• An API or Terraform/Ansible integration
• You specify:
• Region/availability zones
• Cluster name and version (from supported versions)
• Network settings (VPC/VNet, CIDR ranges, private/public API)
• Node pool characteristics (instance types, counts, autoscaling ranges)
• Identity integration options (e.g., IAM roles, AAD groups)
2. Automated provisioning
• The service:
• Creates necessary infrastructure (VPC/VNet resources, subnets, load balancers, security groups, etc.) in a provider-managed account or in your own account, depending on the model
• Deploys OpenShift control plane
• Sets up Operators, ingress, monitoring, and storage integration as per the service defaults
3. Cluster access
• You receive:
• Web console URL
• API endpoint URL
• kubeconfig or oc login mechanism (usually integrated with cloud IAM or your identity provider)
• Onboarding may include:
• Default admin roles
• Recommendations for initial RBAC and project structure
4. Ongoing operations
• Provider:
• Monitors cluster health
• Applies upgrades/patches on agreed schedules or windows
• You:
• Deploy and manage applications
• Adjust node pools and autoscaling as workloads evolve
• Configure cluster policies within allowed scope

Upgrade and Patch Management in Managed Services

One of the main benefits of managed OpenShift is delegated lifecycle management:

• Version availability
• The provider exposes a curated set of OpenShift versions
• Older versions may be phased out on a published schedule
• You have to plan for mandatory upgrades before end-of-support dates
• Upgrade models
• Automatic (provider-initiated) upgrades
• Fully automated upgrades within a maintenance window
• You may be able to opt in/out or set acceptable windows
• Customer-initiated upgrades within constraints
• You choose when to move from version $X$ to $Y$ within a supported range
• Provider orchestrates the process once started
• Impact on workloads
• Control plane upgrades typically are done in a rolling manner
• Worker node upgrades often involve cordon/drain/replace node cycles:
• Pods are rescheduled on other nodes through Kubernetes scheduling
• Stateful workloads must be designed to handle restarts and rescheduling
• For production clusters, you must:
• Test application compatibility on staging clusters
• Validate Operators and CRDs used by your workloads
• Plan around maintenance windows and SLOs
• Security and patch SLAs
• Critical CVEs in OpenShift or OS images may trigger accelerated patch cycles
• Providers typically publish SLAs or policies for security patch turnaround

Networking Considerations in Managed OpenShift

Managed services strongly influence how networking is set up and what you can customize.

Typical aspects:

• Cluster topology
• Public vs private API endpoints:
• Public: API/server and/or ingress reachable from the Internet
• Private: API and/or routes available only through private networks (VPN, Direct Connect/ExpressRoute, peering)
• Single-region vs multi-AZ:
• Most managed offerings support spread across multiple zones for higher availability
• Integration with cloud networking
• Use of provider-native constructs:
• VPC/VNet, subnets, security groups/NSGs, route tables
• Cloud load balancers for ingress and API
• Options for:
• VPC/VNet peering to on-prem or other networks
• VPN/Direct Connect/ExpressRoute to data centers
• Some configuration is:
• Fixed at cluster creation time (e.g., CIDR ranges)
• Restricted to specific patterns validated by the managed service
• Service exposure
• Ingress controllers and Routes are usually preconfigured with:
• Provider-managed load balancers
• TLS termination using provider defaults or customer certificates
• Options for:
• Bring-your-own domain
• Custom certificates
• Private/internal-only ingress
• Security
• Outbound (egress) controls may include:
• Allowed egress ranges or NAT gateways
• Integration with cloud firewalls
• Inbound controls:
• Security groups/NSGs around ingress
• Private vs public load balancer modes

When planning, you must align managed service constraints with organizational network policies, especially in regulated environments.

Storage and Data in Managed OpenShift Services

In managed OpenShift, persistent storage is often implemented using the underlying cloud’s native storage services. The storage integration is preconfigured and supported as part of the service.

Common patterns:

• Default StorageClasses
• Predefined StorageClasses map to:
• Cloud block storage (e.g., EBS, Azure Disk)
• Cloud file storage (e.g., EFS, Azure Files) in some offerings
• Classes may be tuned for:
• Performance tiers (e.g., gp3 vs io2)
• Replication or zone redundancy
• Dynamic provisioning
• PVCs using the default or supported StorageClasses are automatically provisioned
• Quotas and limits may be set by organization or per-project
• Backup and disaster recovery
• Responsibility is often shared:
• Provider:
• Ensures etcd and control plane state is backed up for platform recovery
• Customer:
• Responsible for backup/restore of:
• Application-level data in PVCs
• External data stores and services
• Managed offerings may:
• Provide integration points or recommended backup tools
• Offer optional add-ons for cluster or application backup
• Data residency and compliance
• Region choice dictates physical data location for managed control-plane data
• For application data:
• Underlying cloud policies and region availability apply
• You must consider encryption, key management (KMS), and tenant isolation

Identity, Access Control, and Security in Managed Services

Managed OpenShift services typically integrate tightly with the cloud or enterprise identity ecosystem.

Key points:

• Authentication integration
• Cloud IAM (e.g., AWS IAM, Azure AD) can be used as the identity source
• Users log in via:
• Cloud SSO
• Enterprise IdPs federated into cloud IAM
• Managed service may:
• Restrict direct modification of some identity providers
• Provide guided setup for external IdPs
• Authorization
• You still use OpenShift RBAC to:
• Define cluster roles and role bindings
• Control permissions at project/namespace level
• Cloud-level roles sometimes determine:
• Who can create or administer clusters
• Who is treated as an OpenShift cluster admin by default
• Platform security controls
• Provider may:
• Enforce certain baseline Security Context Constraints (SCCs)
• Restrict privileged containers or host-level access
• Control cluster-level Pod Security and security-sensitive APIs
• Image security:
• Integration with provider image registries (e.g., ECR, ACR)
• Optional or built-in image scanning services
• Compliance:
• Managed offerings often have certifications (e.g., SOC, ISO, some industry standards) that you can leverage
• Responsibility for application-level compliance remains with you

Understanding both OpenShift-level and cloud-level security policy layers is critical for designing secure multi-tenant use of a managed cluster.

Cost and Capacity Management in Managed OpenShift

Managed OpenShift bundles platform operations into a service fee structure. Costs usually break down into:

• Control-plane / platform fee
• Often per cluster and per node, or per core/hour basis
• Covers:
• Managed control plane
• Platform operations and support
• Infrastructure costs
• Charged by the cloud provider for:
• Worker nodes (VM instances, CPU/RAM)
• Storage (block, file, object for backups)
• Load balancers, public IPs, network egress
• Visibility typically via the cloud billing console and possibly provider-specific cost dashboards
• Cost control levers
• Node sizing:
• Choose instance types that match workload profiles (CPU-bound vs memory-bound)
• Autoscaling:
• Cluster autoscaler settings (min/max nodes)
• Horizontal Pod Autoscaler on deployments
• Environment strategy:
• Number of clusters (per env vs multi-tenant)
• Size of non-production clusters
• Quotas and limits:
• Per-project resource quotas
• Restraints on ephemeral resource consumption (e.g., ephemeral storage, load balancers)

Managed services make direct operations cheaper in staff time, but require active capacity and cost governance to avoid overspending.

When to Use Managed OpenShift vs Self-Managed

Managed OpenShift services are not always the right fit. Some considerations:

• Use managed OpenShift when:
• You want to adopt OpenShift quickly without building a platform team first
• Your workloads can run comfortably within the network, security, and configuration boundaries of the chosen cloud
• You value:
• Offloaded upgrades and patching
• Defined SLAs for cluster availability
• Native integration with cloud services and IAM
• You prefer predictable operational models and vendor support
• Consider self-managed (IPI/UPI) when:
• You need:
• Very specific customizations of control plane or underlying OS
• On-prem or highly specialized infrastructure not covered by managed offerings
• Full control over upgrade schedule and configuration
• Regulatory or data-sovereignty requirements cannot be met by any managed offering
• You already have a strong platform engineering/SRE organization prepared to operate the cluster

Often organizations use a hybrid approach: managed OpenShift in public clouds for most workloads, and self-managed clusters in specialized environments.

Practical Implications for Day-to-Day Use

For developers and platform users, working on a managed OpenShift cluster typically feels the same as working on any other OpenShift cluster:

• You still:
• Use oc and the web console
• Create projects, Deployments, Routes, PVCs, etc.
• Rely on Operators and CRDs included in the cluster
• The differences you notice are:
• Some cluster-level settings are read-only or managed by the provider
• Certain powerful capabilities (e.g., host-level access, some SCCs) are restricted
• Some Operators or features may be limited to those supported in the managed environment
• You interact with provider-specific tooling for:
• Creating and deleting clusters
• Adjusting node pools and autoscaling
• Viewing billing and usage metrics

Understanding these boundaries helps you design applications and internal processes that align with the capabilities and constraints of your chosen managed OpenShift service.