Skip to content

Commit 381ad40

Browse files
authored
Merge pull request #70661 from jneczypor/OSDOCS-8402
OSDOCS-8402: Migrate "FAQ" from rosaworkshop.io
2 parents a49db70 + d881331 commit 381ad40

File tree

1 file changed

+166
-5
lines changed

1 file changed

+166
-5
lines changed

cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-what-is-rosa.adoc

Lines changed: 166 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -14,18 +14,179 @@ Red Hat OpenShift Service on AWS (ROSA) is a fully-managed turnkey application p
1414
ROSA makes use of AWS Security Token Service (STS) to obtain credentials to manage infrastructure in your AWS account. AWS STS is a global web service that creates temporary credentials for IAM users or federated users. ROSA uses this to assign short-term, limited-privilege, security credentials. These credentials are associated with IAM roles that are specific to each component that makes AWS API calls. This method aligns with the principals of least privilege and secure practices in cloud service resource management. The ROSA command line interface (CLI) tool manages the STS credentials that are assigned for unique tasks and takes action on AWS resources as part of OpenShift functionality.
1515
//For a detailed explanation, see "ROSA with STS Explained" (add xref when page is migrated).
1616

17+
== Key features of ROSA
18+
* *Native AWS service:* Access and use Red Hat OpenShift on-demand with a self-service onboarding experience through the AWS management console.
19+
* *Flexible, consumption-based pricing:* Scale to your business needs and pay as you go with flexible pricing and an on-demand hourly or annual billing model.
20+
* *Single bill for Red Hat OpenShift and AWS usage:* Customers will receive a single bill from AWS for both Red Hat OpenShift and AWS consumption.
21+
* *Fully integrated support experience:* Installation, management, maintenance, and upgrades are performed by Red Hat site reliability engineers (SREs) with joint Red Hat and Amazon support and a 99.95% service-level agreement (SLA).
22+
* *AWS service integration:* AWS has a robust portfolio of cloud services, such as compute, storage, networking, database, analytics, and machine learning. All of these services are directly accessible through ROSA. This makes it easier to build, operate, and scale globally and on-demand through a familiar management interface.
23+
* *Maximum Availability:* Deploy clusters across multiple availability zones in supported regions to maximize availability and maintain high availability for your most demanding mission-critical applications and data.
24+
* *Cluster node scaling:* Easily add or remove compute nodes to match resource demand.
25+
* *Optimized clusters:* Choose from memory-optimized, compute-optimized, or general purpose EC2 instance types with clusters sized to meet your needs.
26+
* *Global availability:* Refer to the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-regions-az_rosa-service-definition[product regional availability page] to see where ROSA is available globally.
27+
28+
== ROSA and Kubernetes
29+
In ROSA, everything you need to deploy and manage containers is bundled, including container management, Operators, networking, load balancing, service mesh, CI/CD, firewall, monitoring, registry, authentication, and authorization capabilities. These components are tested together for unified operations as a complete platform. Automated cluster operations, including over-the-air platform upgrades, further enhance your Kubernetes experience.
30+
31+
== Basic responsibilities
32+
In general, cluster deployment and upkeep is Red Hat's or AWS's responsibility, while applications, users, and data is the customer's responsibility. For a more detailed breakdown of responsibilities, see the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#rosa-policy-responsibility-matrix[responsibility matrix].
33+
34+
== Roadmap and feature requests
35+
Visit the link:https://github.com/openshift-cs/managed-openshift/projects/2[ROSA roadmap] to stay up-to-date with the status of features currently in development. Open a new issue if you have any suggestions for the product team.
36+
37+
== AWS region availability
38+
Refer to the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-regions-az_rosa-service-definition[product regional availability] page for an up-to-date view of where ROSA is available.
39+
40+
== Compliance certifications
41+
ROSA is currently compliant with SOC-2 type 2, SOC 3, ISO-27001, ISO 27017, ISO 27018, HIPAA, GDPR, and PCI-DSS. We are also currently working towards FedRAMP High.
42+
43+
== Nodes
44+
=== Worker nodes across multiple AWS regions
45+
All nodes in a ROSA cluster must be located in the same AWS region. For clusters configured for multiple availability zones, control plane nodes and worker nodes will be distributed across the availability zones.
46+
47+
=== Minimum number of worker nodes
48+
For a ROSA cluster, the minimum is 2 worker nodes for single availability zone and 3 worker nodes for multiple availability zones.
49+
50+
=== Underlying node operating system
51+
As with all OpenShift v4.x offerings, the control plane, infra and worker nodes run Red Hat Enterprise Linux CoreOS (RHCOS).
52+
53+
=== Node hibernation or shut-down
54+
At this time, ROSA does not have a hibernation or shut-down feature for nodes. The shutdown and hibernation feature is an OpenShift platform feature that is not yet mature enough for widespread cloud services use.
55+
56+
=== Supported instances for worker nodes
57+
For a complete list of supported instances for worker nodes see xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-aws-instance-types_rosa-service-definition[AWS instance types]. Spot instances are also supported.
58+
59+
=== Node autoscaling
60+
Autoscaling allows you to automatically adjust the size of the cluster based on the current workload. See xref:../../rosa_cluster_admin/rosa_nodes/rosa-nodes-about-autoscaling-nodes.adoc#rosa-nodes-about-autoscaling-nodes[About autoscaling nodes on a cluster] for more details.
61+
62+
=== Maximum number of worker nodes
63+
The maximum number of worker nodes is 180 worker nodes for each ROSA cluster. See xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[limits and scalability] for more details on node counts.
64+
1765
A list of the account-wide and per-cluster roles is provided in the xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[ROSA documentation].
1866

67+
== Administrators
68+
A ROSA customer's administrator can manage users and quotas in addition to accessing all user-created projects.
69+
70+
== OpenShift versions and upgrades
71+
ROSA is a managed service which is based on OpenShift Container Platform. You can view the current version and life cycle dates in the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle-dates_rosa-life-cycle[ROSA documentation].
72+
73+
Customers can upgrade to the newest version of OpenShift and use the features from that version of OpenShift. For more information, see xref:../../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle-dates_rosa-life-cycle[life cycle dates]. Not all OpenShift features are be available on ROSA. Review the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-service-definition[Service Definition] for more information.
74+
75+
== Support
76+
You can open a ticket directly from the link:https://console.redhat.com/openshift[Red Hat OpenShift Cluster Manager]. See the xref:../../support/getting-support.adoc#getting-support[ROSA support documentation] for more details about obtaining support.
77+
78+
You can also visit the link:http://access.redhat.com/[Red Hat Customer Portal] to search or browse through the Red Hat knowledge base of articles and solutions relating to Red Hat products or submit a support case to Red Hat Support.
79+
80+
=== Limited support
81+
If a ROSA cluster is not upgraded before the "end of life" date, the cluster continues to operate in a limited support status. The SLA for that cluster will no longer be applicable, but you can still get support for that cluster. See the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle[limited support status] documentation for more details.
82+
83+
.Additional support resources
84+
* link:https://access.redhat.com/[Red Hat Support]
85+
* link:https://aws.amazon.com/premiumsupport/[AWS Support]
86+
+
87+
AWS support customers must have a valid AWS support contract
88+
89+
== Service-level agreement (SLA)
90+
Refer to the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-sla_rosa-service-definition[ROSA SLA] page for details.
91+
92+
== Notifications and communication
93+
Red Hat will provide notifications regarding new Red Hat and AWS features, updates, and scheduled maintenance through email and the Red Hat console service log.
94+
95+
== Open Service Broker for AWS (OBSA)
96+
You can use OSBA with ROSA. However, the preferred method is the more recent link:https://github.com/aws-controllers-k8s/community[AWS Controller for Kubernetes]. See link:https://aws.amazon.com/partners/servicebroker/[Open Service Broker for AWS] for more information on OSBA.
97+
98+
== Offboarding
99+
Customers can stop using ROSA at any time and move their applications to on-premise, a private cloud, or other cloud providers. Standard reserved instances (RI) policy applies for unused RI.
100+
101+
== Authentication
102+
ROSA supports the following authentication mechanisms: OpenID Connect (a profile of OAuth2), Google OAuth, GitHub OAuth, GitLab, and LDAP.
103+
104+
== SRE cluster access
105+
All SRE cluster access is secured by MFA. See xref:../../rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc#rosa-sre-access[SRE access] for more details.
106+
107+
== Encryption
108+
109+
=== Encryption keys
110+
ROSA uses a key stored in KMS to encrypt EBS volumes. Customers also have the option to provide their own KMS keys at cluster creation.
111+
112+
=== KMS keys
113+
If you specify a KMS key, the control plane, infrastructure and worker node root volumes and the persistent volumes are encrypted with the key.
114+
115+
=== Data encryption
116+
By default, there is encryption at rest. The AWS Storage platform automatically encrypts your data before persisting it and decrypts the data before retrieval. See link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[AWS EBS Encryption] for more details.
117+
118+
You can also encrypt etcd in the cluster, combining it with AWS storage encryption. This results in double the encryption which adds up to a 20% performance hit. For more details see the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-service-definition[etcd encryption] documentation.
119+
120+
=== etcd encryption
121+
etcd encryption can only be enabled at cluster creation.
122+
123+
[NOTE]
124+
====
125+
etcd encryption incurs additional overhead with negligible security risk mitigation.
126+
====
127+
128+
=== etcd encryption configuration
129+
etcd encryption is configured the same as in OpenShift Container Platform. The aescbc cypher is used and the setting is patched during cluster deployment. For more details, see the link:https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/[Kubernetes documentation].
130+
131+
=== Multi-region KMS keys for EBS encryption
132+
Currently, the ROSA CLI does not accept multi-region KMS keys for EBS encryption. This feature is in our backlog for product updates. The ROSA CLI accepts single region KMS keys for EBS encryption if it is defined at cluster creation.
133+
134+
== Infrastructure
135+
ROSA uses several different cloud services such as virtual machines, storage, and load balancers. You can see a defined list in the xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-aws-policy-provisioned_rosa-sts-aws-prereqs[AWS prerequisites].
136+
137+
== Credential methods
138+
There are two credential methods to grant Red Hat the permissions needed to perform the required actions in your AWS account: AWS with STS or an IAM user with admin permissions. AWS with STS is the preferred method, and the IAM user method will eventually be deprecated. AWS with STS better aligns with the principles of least privilege and secure practices in cloud service resource management.
139+
//See the section [ROSA with STS Explained] section for a detailed explanation.
140+
141+
== Prerequisite permission or failure errors
142+
Check for a newer version of the ROSA CLI. Every release of the ROSA CLI is located in two places: link:https://github.com/openshift/rosa/releases[Github] and the link:https://www.openshift.com/products/rosa/download[Red Hat signed binary releases].
143+
144+
== Storage
145+
Refer to the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-storage_rosa-service-definition[storage] section of the service definition.
146+
147+
OpenShift includes the CSI driver for AWS EFS. For more information, see xref:../../storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc#osd-persistent-storage-aws-efs-csi[Setting up AWS EFS for Red Hat OpenShift Service on AWS].
148+
149+
== Using a VPC
150+
At installation you can select to deploy to an existing VPC or bring your own VPC. You can then select the required subnets and provide a valid CIDR range that encompasses the subnets for the installation program when using those subnets.
151+
152+
ROSA allows multiple clusters to share the same VPC. The number of clusters on one VPC is limited by the remaining AWS resource quota and CIDR ranges that cannot overlap. See xref:../../networking/cidr-range-definitions.adoc#cidr-range-definitions[CIDR Range Definitions] for more information.
153+
154+
== Network plugin
155+
ROSA uses the OpenShift OVN-Kubernetes default CNI network provider.
156+
157+
== Cross-namespace networking
158+
Cluster admins can customize, and deny, cross-namespace on a project basis using NetworkPolicy objects. Refer to xref:../../networking/network_policy/multitenant-network-policy.adoc[Configuring multitenant isolation with network policy] for more information.
159+
160+
== Using Prometheus and Grafana
161+
You can use Prometheus and Grafana to monitor containers and manage capacity using OpenShift User Workload Monitoring. This is a check-box option in the link:https://console.redhat.com/openshift[OpenShift Cluster Manager].
162+
163+
== Audit logs output from the cluster control-plane
164+
If the Cluster Logging Operator Add-on has been added to the cluster then audit logs are available through CloudWatch. If it has not, then a support request would allow you to request some audit logs. Small targeted and time-boxed logs can be requested for export and sent to a customer. The selection of audit logs available are at the discretion of SRE in the category of platform security and compliance. Requests for exports of a cluster's entirety of logs will be rejected.
165+
166+
== AWS Permissions Boundary
167+
You can use an AWS Permissions Boundary around the policies for your cluster.
168+
169+
== AMI
170+
ROSA worker nodes use a different AMI from OSD and OpenShift Container Platform. Control Plane and Infra node AMIs are common across products in the same version.
171+
172+
== Cluster backups
173+
ROSA STS clusters do not have backups. Users must have their own backup policies for applications and data. See our xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-backup-policy_rosa-service-definition[backup policy] for more information.
174+
175+
== Custom domain
176+
You can define a custom domain for your applications. See xref:../../applications/deployments/osd-config-custom-domains-applications.adoc#osd-config-custom-domains-applications[Configuring custom domains for applications] for more information.
177+
178+
== ROSA domain certificates
179+
Red Hat infrastructure (Hive) manages certificate rotation for default application ingress.
180+
181+
== Disconnected environments
182+
ROSA does not support an air-gapped, disconnected environment. The ROSA cluster must have egress to the internet to access our registry, S3, and send metrics. The service requires a number of egress endpoints.
183+
Ingress can be limited to a PrivateLink for Red Hat SREs and a VPN for customer access.
184+
19185
//== Creating your first ROSA cluster
20186

21187
//Watch this demo for a short preview of the cluster deployment process:
22188
//link:https://youtu.be/KbzUbXWs6Ck
23189

24-
//If you want an easy guide for creating your first ROSA cluster:
25-
26-
//. Review the xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-sts-aws-prereqs[prerequisites].
27-
//. Visit the quickstart guide.
28-
29190
.Additional Resources
30191

31192
* ROSA product pages:

0 commit comments

Comments
 (0)