# Security in ROSA Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](http://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security of the cloud and security in the cloud: + **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](http://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to ROSA, see [AWS services in Scope by Compliance Program](http://aws.amazon.com/compliance/services-in-scope/). + **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations. This documentation helps you understand how to apply the shared responsibility model when using ROSA. It shows you how to configure ROSA to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your ROSA resources. **Topics** + [Data protection](data-protection.md) + [Identity and access management](security-iam.md) + [Resilience](disaster-recovery-resiliency.md) + [Infrastructure security](infrastructure-security.md) # Data protection in ROSA The [Overview of responsibilities for ROSA](rosa-responsibilities.md) documentation and [AWS shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) define data protection in ROSA. AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. Red Hat is responsible for protecting the cluster infrastructure and underlying service platform. The customer is responsible for maintaining control over content that is hosted on this infrastructure. This content includes the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](http://aws.amazon.com/compliance/data-privacy-faq). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](http://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr) blog post on the * AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with AWS CloudTrail. + Use AWS encryption solutions, along with all default security controls within AWS services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-2](http://aws.amazon.com/compliance/fips/). We strongly recommend that you never put sensitive identifying information, such as your customers' account numbers, into free-form fields such as a **Name** field. This includes when you work with ROSA or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into ROSA or other services might get picked up for inclusion in diagnostic logs. When you provide a URL to an external server, don’t include credentials information in the URL to validate your request to that server. **Topics** + [Data encryption](data-protection-encryption.md) # Protecting data using encryption Data protection refers to protecting data while in transit (as it travels to and from ROSA) and at rest (while it is stored on disks in AWS data centers). Red Hat OpenShift Service on AWS provides secure access to Amazon Elastic Block Store (Amazon EBS) storage volumes attached to Amazon EC2 instances for ROSA control plane, infrastructure, and worker nodes, as well as Kubernetes persistent volumes for persistent storage. ROSA encrypts volume data at rest and in transit, and uses AWS Key Management Service (AWS KMS) to help protect your encrypted data. The service uses Amazon S3 for container image registry storage, which is encrypted at rest by default. **Important** Because ROSA is a managed service, AWS and Red Hat manage the infrastructure that ROSA uses. Customers should not attempt to manually shut down the Amazon EC2 instances that ROSA uses from the AWS console or CLI. This action can lead to customer data loss. ## Data encryption for Amazon EBS-backed storage volumes Red Hat OpenShift Service on AWS uses the Kubernetes persistent volume (PV) framework to allow cluster administrators to provision a cluster with persistent storage. Persistent volumes, as well as the control plane, infrastructure, and worker nodes, are backed by Amazon Elastic Block Store (Amazon EBS) storage volumes attached to Amazon EC2 instances. For ROSA persistent volumes and nodes backed by Amazon EBS, encryption operations occur on the servers that host EC2 instances, ensuring the security of both data at rest and data in transit between an instance and its attached storage. For more information, see [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) in the * Amazon EC2 User Guide*. ### Data encryption for the Amazon EBS CSI driver and Amazon EFS CSI driver ROSA defaults to using the Amazon EBS CSI driver to provision Amazon EBS storage. The Amazon EBS CSI driver and Amazon EBS CSI Driver Operator are installed on the cluster by default in the `openshift-cluster-csi-drivers` namespace. The Amazon EBS CSI driver and operator allow you to dynamically provision persistent volumes and create volume snapshots. ROSA is also capable of provisioning persistent volumes using the Amazon EFS CSI driver and Amazon EFS CSI Driver Operator. The Amazon EFS driver and operator also allow you to share file system data between pods or with other applications within or outside of Kubernetes. Volume data is secured in transit for both the Amazon EBS CSI driver and Amazon EFS CSI driver. For more information, see [Using Container Storage Interface (CSI)](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/storage/using-container-storage-interface-csi) in the Red Hat documentation. **Important** When dynamically provisioning ROSA persistent volumes using the Amazon EFS CSI driver, Amazon EFS considers the user ID, group ID (GID), and secondary group IDs of the access point when evaluating file system permissions. Amazon EFS replaces the user and group IDs on files with the user and group IDs on the access point and ignores NFS client IDs. As a result, Amazon EFS silently ignores `fsGroup` settings. ROSA is not able to replace the GIDs of files by using `fsGroup`. Any pod that can access a mounted Amazon EFS access point can access any file on the volume. For more information, see [Working with Amazon EFS access points](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) in the * Amazon EFS User Guide*. ### etcd encryption ROSA provides the option to enable encryption of `etcd` key values within the `etcd` volume during cluster creation, adding an additional layer of encryption. Once `etcd` is encrypted, you will incur approximately 20% additional performance overhead. We recommend that you enable `etcd` encryption only if you specifically require it for your use case. For more information, see [etcd encryption](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/introduction_to_rosa/policies-and-service-definition#rosa-sdpolicy-etcd-encryption_rosa-service-definition) in the ROSA service definition. ### Key management ROSA uses KMS keys to securely manage control plane, infrastructure, and worker data volumes and persistent volumes for customer applications. During cluster creation, you have the choice of using the default AWS managed KMS key provided by Amazon EBS, or specifying your own customer managed key. For more information, see [Data encryption using KMS](data-protection-key-management.md). ## Data encryption for the built-in image registry ROSA provides a built-in container image registry to store, retrieve, and share container images via Amazon S3 bucket storage. The registry is configured and managed by the OpenShift Image Registry Operator. It provides an out-of-the-box solution for users to manage the images that run their workloads, and runs on top of the existing cluster infrastructure. For more information, see [Registry](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/registry/index) in the Red Hat documentation. ROSA offers public and private image registries. For enterprise applications, we recommend using a private registry to protect your images from being used by unauthorized users. To protect your registry’s data at rest, ROSA uses server-side encryption by default with Amazon S3 managed keys (SSE-S3). This does not require any action on your part, and is offered at no additional charge. For more information, see [Protecting data using server-side encryption with Amazon S3 managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) in the * Amazon S3 User Guide*. ROSA uses Transport Layer Security (TLS) protocol to secure data in transit to and from the image registry. For more information, see [Registry](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/registry/index) in the Red Hat documentation. ## Internetwork traffic privacy Red Hat OpenShift Service on AWS uses Amazon Virtual Private Cloud (Amazon VPC) to create boundaries between resources in your ROSA cluster and control traffic between them, your on-premises network, and the internet. For more information about Amazon VPC security, see [Internetwork traffic privacy in Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) in the * Amazon VPC User Guide*. Within the VPC, you can configure your ROSA clusters to use an HTTP or HTTPS proxy server to deny direct internet access. If you are a cluster administrator, you can also define network policies at the pod level that restrict internetwork traffic to pods in your ROSA cluster. For more information, see [Infrastructure security in ROSA](infrastructure-security.md). # Data encryption using KMS ROSA uses AWS KMS to securely manage keys for encrypted data. Control plane, infrastructure, and worker node volumes are encrypted by default using the AWS managed KMS key provided by Amazon EBS. This KMS key has the alias `aws/ebs`. Persistent volumes that use the default gp3 storage class are also encrypted by default using this KMS key. Newly created ROSA clusters are configured to use the default gp3 storage class to encrypt persistent volumes. Persistent volumes created by using any other storage class are only encrypted if the storage class is configured to be encrypted. For more information about ROSA pre-built storage classes, see [Configuring persistent storage](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/storage/configuring-persistent-storage#persistent-storage-aws) in the Red Hat documentation. During cluster creation, you can choose to encrypt the persistent volumes in your cluster using the default Amazon EBS-provided key, or specify your own customer managed symmetric KMS key. For more information about creating keys, see [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) in the * AWS KMS Developer Guide*. You can also encrypt persistent volumes for individual containers within a cluster by defining a KMS key. This is useful when you have explicit compliance and security guidelines when deploying to AWS. For more information, see [Encrypting container persistent volumes on AWS with a KMS key](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/storage/configuring-persistent-storage#aws-container-persistent-volumes-encrypt_persistent-storage-aws) in the Red Hat documentation. The following points should be considered when encrypting persistent volumes using your own KMS keys: + When you use KMS encryption with your own KMS key, the key must exist in the same AWS Region as your cluster. + There is a cost associated with creating and using your own KMS keys. For more information, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/). # Identity and access management for ROSA AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use ROSA resources. IAM is an AWS service that you can use with no additional charge. **Topics** + [Audience](#security-iam-audience) + [Authenticating with identities](#security-iam-authentication) + [Managing access using policies](#security-iam-access-manage) + [ROSA identity-based policy examples](security-iam-id-based-policy-examples.md) + [AWS managed policies for ROSA](security-iam-awsmanpol.md) + [Troubleshooting ROSA identity and access](security-iam-troubleshoot.md) ## Audience How you use AWS Identity and Access Management (IAM) differs, depending on the work you do in ROSA. **Service user** - If you use the ROSA service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more ROSA features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in ROSA, see [Troubleshooting ROSA identity and access](security-iam-troubleshoot.md). **Service administrator** - If you’re in charge of ROSA resources at your company, you probably have full access to ROSA. It’s your job to determine which ROSA features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. ** IAM administrator** - If you’re an IAM administrator, you might want to learn details about the policies used to manage access to ROSA. To view example ROSA identity-based policies that you can use in IAM, see [ROSA identity-based policy examples](security-iam-id-based-policy-examples.md). ## Authenticating with identities Authentication is how you sign in to AWS using your identity credentials. You must be *authenticated* (signed in to AWS) as the AWS account root user, an IAM user, or by assuming an IAM role. You can sign in to AWS as a federated identity by using credentials provided through an identity source. AWS IAM Identity Center (IAM Identity Center) users, your company’s single sign-on authentication, and your Google or Facebook credentials are examples of federated identities. When you sign in as a federated identity, your administrator previously set up identity federation using IAM roles. When you access AWS by using federation, you are indirectly assuming a role. Depending on the type of user you are, you can sign in to the AWS Management Console or the AWS access portal. For more information about signing in to AWS, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the * AWS Sign-In User Guide*. If you access AWS programmatically, AWS provides a software development kit (SDK) and a command line interface (CLI) to cryptographically sign your requests using your credentials. If you don’t use AWS tools, you must sign requests yourself. For more information about using the recommended method to sign requests yourself, see [Signing AWS API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) in the * IAM User Guide*. Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the * AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide* and [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*. ### AWS account root user When you create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you don’t use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html) in the * IAM User Guide*. ### Federated identity As a best practice, require human users, including users that require administrator access, to use federation with an identity provider to access AWS services by using temporary credentials. A federated identity is a user from your enterprise user directory, a web identity provider, the AWS Directory Service, the Identity Center directory, or any user that accesses AWS services by using credentials provided through an identity source. When federated identities access AWS accounts, they assume roles, and the roles provide temporary credentials. For centralized access management, we recommend that you use AWS IAM Identity Center. You can create users and groups in IAM Identity Center, or you can connect and synchronize to a set of users and groups in your own identity source for use across all your AWS accounts and applications. For information about IAM Identity Center, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the * AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*. ### IAM users and groups An * [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) * is an identity within your AWS account that has specific permissions for a single person or application. Where possible, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see [Rotate access keys regularly for use cases that require long-term credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) in the *IAM User Guide*. An [IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is an identity that specifies a collection of IAM users. You can’t sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named *IAMAdmins* and give that group permissions to administer IAM resources. Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see [When to create an IAM user (instead of a role)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) in the *IAM User Guide*. ### IAM roles An * [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) * is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by [switching roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see [Using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the *IAM User Guide*. IAM roles with temporary credentials are useful in the following situations: + **Federated user access** - To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [Creating a role for a third-party Identity Provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the * AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*. + **Temporary IAM user permissions** - An IAM user can assume an IAM role to temporarily take on different permissions for a specific task. + **Cross-account access** - You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. + **Cross-service access** - Some AWS services use features in other AWS services. For example, when you make a call in a service, it’s common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal’s permissions, using a service role, or using a service-linked role. + **Forward access sessions** (FAS) - When you use an IAM user or role to perform actions in AWS, you are considered a principal. When you use some services, you might perform an action that then initiates another action in a different service. FAS uses the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. FAS requests are only made when a service receives a request that requires interactions with other AWS services or resources to complete. In this case, you must have permissions to perform both actions. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). + **Service role** - A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. + **Service-linked role** - A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. + **Applications running on Amazon EC2 ** - You can use an IAM role to manage temporary credentials for applications that are running on an Amazon EC2 instance and making AWS CLI or AWS API requests. This is preferable to storing access keys within the Amazon EC2 instance. To assign an AWS role to an Amazon EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the Amazon EC2 instance to get temporary credentials. For more information, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*. To learn whether to use IAM roles or IAM users, see [When to create an IAM role (instead of a user)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) in the *IAM User Guide*. ## Managing access using policies You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*. Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. By default, users and roles have no permissions. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. The administrator can then add the IAM policies to roles, and users can assume the roles. IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the `iam:GetRole` action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API. ### Identity-based policies Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, role, or group. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. Identity-based policies can be further categorized as *inline policies* or *managed policies*. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see [Choosing between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) in the *IAM User Guide*. ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services. Resource-based policies are inline policies that are located in that service. You can’t use AWS managed policies from IAM in a resource-based policy. ### Access control lists (ACLs) Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access Control List (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service User Guide*. ### Other policy types AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types. + **Permissions boundaries** - A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity (IAM user or role). You can set a permissions boundary for an entity. The resulting permissions are the intersection of entity’s identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role in the `Principal` field are not limited by the permissions boundary. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*. + **Service control policies (SCPs)** - SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations. AWS Organizations is a service for grouping and centrally managing multiple AWS accounts that your business owns. If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. The SCP limits permissions for entities in member accounts, including each AWS account root user. For more information about Organizations and SCPs, see [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the * AWS Organizations User Guide*. + **Session policies** - Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The resulting session’s permissions are the intersection of the user or role’s identity-based policies and the session policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*. ### Multiple policy types When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. # ROSA identity-based policy examples By default, IAM users and roles don’t have permission to create or modify AWS resources. They also can’t perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions. To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*. ## Using the ROSA console To subscribe to ROSA from the console, your IAM principal must have the required AWS Marketplace permissions. The permissions allow the principal to subscribe and unsubscribe to the ROSA product listing in AWS Marketplace and view AWS Marketplace subscriptions. To add the required permissions, go to the [ROSA console](https://console.aws.amazon.com/rosa) and attach the AWS managed policy `ROSAManageSubscription` to your IAM principal. For more information about `ROSAManageSubscription`, see [AWS managed policy: ROSAManageSubscription](security-iam-awsmanpol.md#security-iam-awsmanpol-rosamanagesubscription). ## Authorizing ROSA with HCP to manage AWS resources ROSA with hosted control planes (HCP) uses AWS managed policies with permissions that are required for service operation and support. You use the ROSA CLI or IAM console to attach these policies to service roles in your AWS account. For more information, see [AWS managed policies for ROSA](security-iam-awsmanpol.md). ## Authorizing ROSA classic to manage AWS resources ROSA classic uses customer managed IAM policies with permissions that are pre-defined by the service. You use the ROSA CLI to create these policies and attach them to service roles in your AWS account. ROSA requires that these policies are configured as defined by the service to ensure continuous operation and service support. **Note** You should not alter ROSA classic policies without first consulting Red Hat. Doing so may void Red Hat’s 99.95% cluster uptime service-level agreement. ROSA with hosted control planes uses AWS managed policies with a more limited set of permissions. For more information, see [AWS managed policies for ROSA](security-iam-awsmanpol.md). There are two types of customer managed policies for ROSA: account policies and operator policies. Account policies are attached to IAM roles that the service uses to establish a trust relationship with Red Hat for site reliability engineer (SRE) support, cluster creation, and compute functionality. Operator policies are attached to IAM roles that OpenShift operators use for cluster operations related to ingress, storage, image registry, and node management. Account policies are created once per AWS account, whereas operator polices are created once per cluster. For more information, see [ROSA classic account policies](security-iam-rosa-classic-account-policies.md) and [ROSA classic operator policies](security-iam-rosa-classic-operator-policies.md). ## Allow users to view their own permissions This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Effect": "Allow", "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Effect": "Allow", "Resource": "*" } ] } ``` # ROSA classic account policies This section provides details about the account policies that are required for ROSA classic. These permissions are needed for ROSA classic to manage the AWS resources that clusters run on and enable Red Hat site reliability engineer support for clusters. You can assign a custom prefix to the policy names, but these policies should otherwise be named as defined on this page (for example, `ManagedOpenShift-Installer-Role-Policy`). The account policies are specific to an OpenShift minor release version and are backward compatible. Before creating or upgrading a cluster, you should verify that the policy version and cluster version are the same by running `rosa list account-roles`. If the policy version is less than the cluster version, run `rosa upgrade account-roles` to upgrade the roles and attached policies. You can use the same account policies and roles for multiple clusters of the same minor release version. ## [Prefix]-Installer-Role-Policy You can attach `[Prefix]-Installer-Role-Policy` to your IAM entities. Before you can create a ROSA classic cluster, you must first attach this policy to an IAM role named `[Prefix]-Installer-Role`. This policy grants required permissions that allow the ROSA installer to manage the AWS resources that are needed for cluster creation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "ec2:AllocateAddress", "ec2:AssociateAddress", "ec2:AssociateDhcpOptions", "ec2:AssociateRouteTable", "ec2:AttachInternetGateway", "ec2:AttachNetworkInterface", "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:CopyImage", "ec2:CreateDhcpOptions", "ec2:CreateInternetGateway", "ec2:CreateNatGateway", "ec2:CreateNetworkInterface", "ec2:CreateRoute", "ec2:CreateRouteTable", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateVpc", "ec2:CreateVpcEndpoint", "ec2:DeleteDhcpOptions", "ec2:DeleteInternetGateway", "ec2:DeleteNatGateway", "ec2:DeleteNetworkInterface", "ec2:DeleteRoute", "ec2:DeleteRouteTable", "ec2:DeleteSecurityGroup", "ec2:DeleteSnapshot", "ec2:DeleteSubnet", "ec2:DeleteTags", "ec2:DeleteVolume", "ec2:DeleteVpc", "ec2:DeleteVpcEndpoints", "ec2:DeregisterImage", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeDhcpOptions", "ec2:DescribeImages", "ec2:DescribeInstanceAttribute", "ec2:DescribeInstanceCreditSpecifications", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeInstanceTypes", "ec2:DescribeInternetGateways", "ec2:DescribeKeyPairs", "ec2:DescribeNatGateways", "ec2:DescribeNetworkAcls", "ec2:DescribeNetworkInterfaces", "ec2:DescribePrefixLists", "ec2:DescribeRegions", "ec2:DescribeReservedInstancesOfferings", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSecurityGroupRules", "ec2:DescribeSubnets", "ec2:DescribeTags", "ec2:DescribeVolumes", "ec2:DescribeVpcAttribute", "ec2:DescribeVpcClassicLink", "ec2:DescribeVpcClassicLinkDnsSupport", "ec2:DescribeVpcEndpoints", "ec2:DescribeVpcs", "ec2:DetachInternetGateway", "ec2:DisassociateRouteTable", "ec2:GetConsoleOutput", "ec2:GetEbsDefaultKmsKeyId", "ec2:ModifyInstanceAttribute", "ec2:ModifyNetworkInterfaceAttribute", "ec2:ModifySubnetAttribute", "ec2:ModifyVpcAttribute", "ec2:ReleaseAddress", "ec2:ReplaceRouteTableAssociation", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:RunInstances", "ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances", "elasticloadbalancing:AddTags", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:AttachLoadBalancerToSubnets", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateLoadBalancerListeners", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:DescribeAccountLimits", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetGroupAttributes", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:SetLoadBalancerPoliciesOfListener", "iam:AddRoleToInstanceProfile", "iam:CreateInstanceProfile", "iam:DeleteInstanceProfile", "iam:GetInstanceProfile", "iam:TagInstanceProfile", "iam:GetRole", "iam:GetRolePolicy", "iam:GetUser", "iam:ListAttachedRolePolicies", "iam:ListInstanceProfiles", "iam:ListInstanceProfilesForRole", "iam:ListRolePolicies", "iam:ListRoles", "iam:ListUserPolicies", "iam:ListUsers", "iam:RemoveRoleFromInstanceProfile", "iam:SimulatePrincipalPolicy", "iam:TagRole", "iam:UntagRole", "route53:ChangeResourceRecordSets", "route53:ChangeTagsForResource", "route53:CreateHostedZone", "route53:DeleteHostedZone", "route53:GetAccountLimit", "route53:GetChange", "route53:GetHostedZone", "route53:ListHostedZones", "route53:ListHostedZonesByName", "route53:ListResourceRecordSets", "route53:ListTagsForResource", "route53:UpdateHostedZoneComment", "s3:CreateBucket", "s3:DeleteBucket", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:GetAccelerateConfiguration", "s3:GetBucketAcl", "s3:GetBucketCORS", "s3:GetBucketLocation", "s3:GetBucketLogging", "s3:GetBucketObjectLockConfiguration", "s3:GetBucketPolicy", "s3:GetReplicationConfiguration", "s3:GetBucketRequestPayment", "s3:GetBucketTagging", "s3:GetBucketVersioning", "s3:GetBucketWebsite", "s3:GetEncryptionConfiguration", "s3:GetLifecycleConfiguration", "s3:GetObject", "s3:GetObjectAcl", "s3:GetObjectTagging", "s3:GetObjectVersion", "s3:GetReplicationConfiguration", "s3:ListBucket", "s3:ListBucketVersions", "s3:PutBucketAcl", "s3:PutBucketTagging", "s3:PutBucketVersioning", "s3:PutEncryptionConfiguration", "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectTagging", "servicequotas:GetServiceQuota", "servicequotas:ListAWSDefaultServiceQuotas", "sts:AssumeRole", "sts:AssumeRoleWithWebIdentity", "sts:GetCallerIdentity", "tag:GetResources", "tag:UntagResources", "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServicePermissions", "ec2:DescribeVpcEndpointServices", "ec2:ModifyVpcEndpointServicePermissions", "kms:DescribeKey", "cloudwatch:GetMetricData" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "secretsmanager:GetSecretValue" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/red-hat-managed": "true" } } } ] } ``` ## [Prefix]-ControlPlane-Role-Policy You can attach `[Prefix]-ControlPlane-Role-Policy` to your IAM entities. Before you can create a ROSA classic cluster, you must first attach this policy to an IAM role named `[Prefix]-ControlPlane-Role`. This policy grants required permissions to ROSA classic to manage Amazon EC2 and Elastic Load Balancing resources that host the ROSA control plane, as well as read KMS keys. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:AttachVolume", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteSecurityGroup", "ec2:DeleteVolume", "ec2:Describe*", "ec2:DetachVolume", "ec2:ModifyInstanceAttribute", "ec2:ModifyVolume", "ec2:RevokeSecurityGroupIngress", "elasticloadbalancing:AddTags", "elasticloadbalancing:AttachLoadBalancerToSubnets", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateLoadBalancerPolicy", "elasticloadbalancing:CreateLoadBalancerListeners", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:DeleteListener", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteLoadBalancerListeners", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:Describe*", "elasticloadbalancing:DetachLoadBalancerFromSubnets", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer", "elasticloadbalancing:SetLoadBalancerPoliciesOfListener", "kms:DescribeKey" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## [Prefix]-Worker-Role-Policy You can attach `[Prefix]-Worker-Role-Policy` to your IAM entities. Before you can create a ROSA classic cluster, you must first attach this policy to an IAM role named `[Prefix]-Worker-Role`. This policy grants required permissions to ROSA classic to describe the EC2 instances running as worker nodes. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstances", "ec2:DescribeRegions" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## [Prefix]-Support-Role-Policy You can attach `[Prefix]-Support-Role-Policy` to your IAM entities. Before you can create a ROSA classic cluster, you must first attach this policy to an IAM role named `[Prefix]-Support-Role`. This policy grants required permissions to Red Hat site reliability engineering to observe, diagnose, and support the AWS resources that ROSA classic clusters use, including the ability to change cluster node state. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "cloudtrail:DescribeTrails", "cloudtrail:LookupEvents", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "ec2-instance-connect:SendSerialConsoleSSHPublicKey", "ec2:CopySnapshot", "ec2:CreateNetworkInsightsPath", "ec2:CreateSnapshot", "ec2:CreateSnapshots", "ec2:CreateTags", "ec2:DeleteNetworkInsightsAnalysis", "ec2:DeleteNetworkInsightsPath", "ec2:DeleteTags", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAddressesAttribute", "ec2:DescribeAggregateIdFormat", "ec2:DescribeAvailabilityZones", "ec2:DescribeByoipCidrs", "ec2:DescribeCapacityReservations", "ec2:DescribeCarrierGateways", "ec2:DescribeClassicLinkInstances", "ec2:DescribeClientVpnAuthorizationRules", "ec2:DescribeClientVpnConnections", "ec2:DescribeClientVpnEndpoints", "ec2:DescribeClientVpnRoutes", "ec2:DescribeClientVpnTargetNetworks", "ec2:DescribeCoipPools", "ec2:DescribeCustomerGateways", "ec2:DescribeDhcpOptions", "ec2:DescribeEgressOnlyInternetGateways", "ec2:DescribeIamInstanceProfileAssociations", "ec2:DescribeIdentityIdFormat", "ec2:DescribeIdFormat", "ec2:DescribeImageAttribute", "ec2:DescribeImages", "ec2:DescribeInstanceAttribute", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeInstanceTypes", "ec2:DescribeInternetGateways", "ec2:DescribeIpv6Pools", "ec2:DescribeKeyPairs", "ec2:DescribeLaunchTemplates", "ec2:DescribeLocalGatewayRouteTables", "ec2:DescribeLocalGatewayRouteTableVirtualInterfaceGroupAssociations", "ec2:DescribeLocalGatewayRouteTableVpcAssociations", "ec2:DescribeLocalGateways", "ec2:DescribeLocalGatewayVirtualInterfaceGroups", "ec2:DescribeLocalGatewayVirtualInterfaces", "ec2:DescribeManagedPrefixLists", "ec2:DescribeNatGateways", "ec2:DescribeNetworkAcls", "ec2:DescribeNetworkInsightsAnalyses", "ec2:DescribeNetworkInsightsPaths", "ec2:DescribeNetworkInterfaces", "ec2:DescribePlacementGroups", "ec2:DescribePrefixLists", "ec2:DescribePrincipalIdFormat", "ec2:DescribePublicIpv4Pools", "ec2:DescribeRegions", "ec2:DescribeReservedInstances", "ec2:DescribeRouteTables", "ec2:DescribeScheduledInstances", "ec2:DescribeSecurityGroupReferences", "ec2:DescribeSecurityGroupRules", "ec2:DescribeSecurityGroups", "ec2:DescribeSnapshotAttribute", "ec2:DescribeSnapshots", "ec2:DescribeSpotFleetInstances", "ec2:DescribeStaleSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeTags", "ec2:DescribeTransitGatewayAttachments", "ec2:DescribeTransitGatewayConnectPeers", "ec2:DescribeTransitGatewayConnects", "ec2:DescribeTransitGatewayMulticastDomains", "ec2:DescribeTransitGatewayPeeringAttachments", "ec2:DescribeTransitGatewayRouteTables", "ec2:DescribeTransitGateways", "ec2:DescribeTransitGatewayVpcAttachments", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications", "ec2:DescribeVolumeStatus", "ec2:DescribeVpcAttribute", "ec2:DescribeVpcClassicLink", "ec2:DescribeVpcClassicLinkDnsSupport", "ec2:DescribeVpcEndpointConnectionNotifications", "ec2:DescribeVpcEndpointConnections", "ec2:DescribeVpcEndpoints", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServicePermissions", "ec2:DescribeVpcEndpointServices", "ec2:DescribeVpcPeeringConnections", "ec2:DescribeVpcs", "ec2:DescribeVpnConnections", "ec2:DescribeVpnGateways", "ec2:GetAssociatedIpv6PoolCidrs", "ec2:GetConsoleOutput", "ec2:GetManagedPrefixListEntries", "ec2:GetSerialConsoleAccessStatus", "ec2:GetTransitGatewayAttachmentPropagations", "ec2:GetTransitGatewayMulticastDomainAssociations", "ec2:GetTransitGatewayPrefixListReferences", "ec2:GetTransitGatewayRouteTableAssociations", "ec2:GetTransitGatewayRouteTablePropagations", "ec2:ModifyInstanceAttribute", "ec2:RebootInstances", "ec2:RunInstances", "ec2:SearchLocalGatewayRoutes", "ec2:SearchTransitGatewayMulticastGroups", "ec2:SearchTransitGatewayRoutes", "ec2:StartInstances", "ec2:StartNetworkInsightsAnalysis", "ec2:StopInstances", "ec2:TerminateInstances", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:DescribeAccountLimits", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeListenerCertificates", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DescribeLoadBalancerPolicies", "elasticloadbalancing:DescribeLoadBalancerPolicyTypes", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeSSLPolicies", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetGroupAttributes", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "iam:GetRole", "iam:ListRoles", "kms:CreateGrant", "route53:GetHostedZone", "route53:GetHostedZoneCount", "route53:ListHostedZones", "route53:ListHostedZonesByName", "route53:ListResourceRecordSets", "s3:GetBucketTagging", "s3:GetObjectAcl", "s3:GetObjectTagging", "s3:ListAllMyBuckets", "sts:DecodeAuthorizationMessage", "tiros:CreateQuery", "tiros:GetQueryAnswer", "tiros:GetQueryExplanation" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "s3:ListBucket" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::managed-velero*", "arn:aws:s3:::*image-registry*" ] } ] } ``` # ROSA classic operator policies This section provides details about the operator policies that are required for ROSA classic. Before you can create a ROSA classic cluster, you must first attach these policies to the relevant operator roles. A unique set of operator roles is required for each cluster. These permissions are needed to allow the OpenShift operators to manage ROSA classic cluster nodes. You can assign a custom prefix to the policy names to simplify policy management (for example, `ManagedOpenShift-openshift-ingress-operator-cloud-credentials`). ## [Prefix]-openshift-ingress-operator-cloud-credentials You can attach `[Prefix]-openshift-ingress-operator-cloud-credentials` to your IAM entities. This policy grants required permissions to the Ingress Operator to provision and manage load balancers and DNS configurations for external cluster access. The policy also allows the Ingress Operator to read and filter Route 53 resource tag values to discover hosted zones. For more information about the operator, see [OpenShift Ingress Operator](https://github.com/openshift/cluster-ingress-operator) in the OpenShift GitHub documentation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "elasticloadbalancing:DescribeLoadBalancers", "route53:ListHostedZones", "route53:ListTagsForResources", "route53:ChangeResourceRecordSets", "tag:GetResources" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## [Prefix]-openshift-cluster-csi-drivers-ebs-cloud-credentials You can attach `[Prefix]-openshift-cluster-csi-drivers-ebs-cloud-credentials` to your IAM entities. This policy grants required permissions to the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA classic cluster. For more information about the operator, see [aws-ebs-csi-driver-operator](https://github.com/openshift/aws-ebs-csi-driver-operator#aws-ebs-csi-driver-operator) in the OpenShift GitHub documentation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:AttachVolume", "ec2:CreateSnapshot", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteSnapshot", "ec2:DeleteTags", "ec2:DeleteVolume", "ec2:DescribeAvailabilityZones", "ec2:DescribeInstances", "ec2:DescribeSnapshots", "ec2:DescribeTags", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications", "ec2:DetachVolume", "ec2:EnableFastSnapshotRestores", "ec2:ModifyVolume" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## [Prefix]-openshift-machine-api-aws-cloud-credentials You can attach `[Prefix]-openshift-machine-api-aws-cloud-credentials` to your IAM entities. This policy grants required permissions to the Machine Config Operator to describe, run, and terminate Amazon EC2 instances managed as worker nodes. This policy also grants permissions to allow for disk encryption of the worker node root volume using AWS KMS keys. For more information about the operator, see [machine-config-operator](https://github.com/openshift/machine-config-operator) in the OpenShift GitHub documentation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:CreateTags", "ec2:DescribeAvailabilityZones", "ec2:DescribeDhcpOptions", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeInternetGateways", "ec2:DescribeInstanceTypes", "ec2:DescribeSecurityGroups", "ec2:DescribeRegions", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:RunInstances", "ec2:TerminateInstances", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:DeregisterTargets", "iam:CreateServiceLinkedRole" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlainText", "kms:DescribeKey" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "kms:RevokeGrant", "kms:CreateGrant", "kms:ListGrants" ], "Effect": "Allow", "Resource": "*", "Condition": { "Bool": { "kms:GrantIsForAWSResource": true } } } ] } ``` ## [Prefix]-openshift-cloud-credential-operator-cloud-credentials You can attach `[Prefix]-openshift-cloud-credential-operator-cloud-credentials` to your IAM entities. This policy grants required permissions to the Cloud Credential Operator to retrieve IAM user details, including access key IDs, attached inline policy documents, user’s creation date, path, user ID, and Amazon Resource Name (ARN). For more information about the operator, see [cloud-credential-operator](https://github.com/openshift/cloud-credential-operator) in the OpenShift GitHub documentation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "iam:GetUser", "iam:GetUserPolicy", "iam:ListAccessKeys" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## [Prefix]-openshift-image-registry-installer-cloud-credentials You can attach `[Prefix]-openshift-image-registry-installer-cloud-credentials` to your IAM entities. This policy grants required permissions to the Image Registry Operator to provision and manage resources for ROSA classic’s in-cluster image registry and dependent services, including Amazon S3. This is required so that the operator can install and maintain the internal registry of a ROSA classic cluster. For more information about the operator, see [Image Registry Operator](https://github.com/openshift/cluster-image-registry-operator#image-registry-operator) in the OpenShift GitHub documentation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutBucketPublicAccessBlock", "s3:GetBucketPublicAccessBlock", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## [Prefix]-openshift-cloud-network-config-controller-cloud-cr You can attach `[Prefix]-openshift-cloud-network-config-controller-cloud-cr` to your IAM entities. This policy grants required permissions to the Cloud Network Config Controller Operator to provision and manage networking resources for use by the ROSA classic cluster networking overlay. The operator uses these permissions to manage private IP addresses for Amazon EC2 instances as part of the ROSA classic cluster. For more information about the operator, see [Cloud-network-config-controller](https://github.com/openshift/cloud-network-config-controller#cloud-network-config-controller-cncc) in the OpenShift GitHub documentation. ### Permissions policy Permissions defined in this policy document specify which actions are allowed or denied. ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypes", "ec2:UnassignPrivateIpAddresses", "ec2:AssignPrivateIpAddresses", "ec2:UnassignIpv6Addresses", "ec2:AssignIpv6Addresses", "ec2:DescribeSubnets", "ec2:DescribeNetworkInterfaces" ], "Effect": "Allow", "Resource": "*" } ] } ``` # AWS managed policies for ROSA An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they’re available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the * IAM User Guide*. ## AWS managed policy: ROSAManageSubscription You can attach the `ROSAManageSubscription` policy to your IAM entities. Before you enable ROSA in the AWS ROSA console, you must first attach this policy to an IAM role. This policy grants the AWS Marketplace permissions required for you to manage the ROSA subscription. **Permissions details** This policy includes the following permissions. + `aws-marketplace:Subscribe` - Grants permission to subscribe to the AWS Marketplace product for ROSA. + `aws-marketplace:Unsubscribe` - Allows principals to remove subscriptions to AWS Marketplace products. + `aws-marketplace:ViewSubscriptions` - Allows principals to view subscriptions from AWS Marketplace. This is required so that the IAM principal can view the available AWS Marketplace subscriptions. To view the full JSON policy document, see [ROSAManageSubscription](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html) in the * AWS Managed Policy Reference Guide*. ## ROSA with HCP account policies This section provides details about the account policies that are required for ROSA with hosted control planes (HCP). These AWS managed policies add permissions used by ROSA with HCP IAM roles. The permissions are required for Red Hat site reliability engineering (SRE) technical support, cluster installation, and control plane and compute functionality. **Note** AWS managed policies are intended for use by ROSA with hosted control planes (HCP). ROSA classic clusters use customer managed IAM policies. For more information about ROSA classic policies, see [ROSA classic account policies](security-iam-rosa-classic-account-policies.md) and [ROSA classic operator policies](security-iam-rosa-classic-operator-policies.md). ### AWS managed policy: ROSAWorkerInstancePolicy You can attach `ROSAWorkerInstancePolicy` to your IAM entities. Before creating a cluster, you must have an IAM role with this policy attached. A ROSA service makes calls to other AWS services on your behalf. They do this to manage the resources that you use with each cluster. **Permissions details** This policy includes the following permissions that allow the ROSA worker nodes to complete the following tasks: + `ec2` — Evaluate AWS Region and Amazon EC2 instance details as part of ROSA cluster worker node lifecycle management. + `ecr` - Evaluate and get images from ROSA-managed ECR repositories that are necessary for cluster installation and worker node lifecycle management. To view the full JSON policy document, see [ROSAWorkerInstancePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAWorkerInstancePolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSASRESupportPolicy You can attach `ROSASRESupportPolicy` to your IAM entities. Before you create a ROSA with hosted control planes cluster, you must first attach this policy to an IAM role. This policy grants required permissions to Red Hat site reliability engineers (SREs) to directly observe, diagnose, and support AWS resources associated with ROSA clusters, including the ability to change ROSA cluster node state. **Permissions details** This policy includes the following permissions that allow Red Hat SREs to complete the following tasks: + `cloudtrail` — Read AWS CloudTrail events and trails relevant to the cluster. + `cloudwatch` — Read Amazon CloudWatch metrics relevant to the cluster. + `ec2` — Read, describe, and review Amazon EC2 components related to the cluster’s health such as security groups, VPC endpoint connections, and volume status. Launch, stop, reboot, and terminate Amazon EC2 instances. + `elasticloadbalancing` — Read, describe, and review Elastic Load Balancing parameters related to the cluster’s health. + `iam` — Evaluate IAM roles that relate to the cluster’s health. + `route53` — Review DNS settings related to the cluster’s health. + `sts` — `DecodeAuthorizationMessage` — Read IAM messages for debugging purposes. To view the full JSON policy document, see [ROSASRESupportPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSAInstallerPolicy You can attach `ROSAInstallerPolicy` to your IAM entities. Before you create a ROSA with hosted control planes cluster, you must first attach this policy to an IAM role named `[Prefix]-ROSA-Worker-Role`. This policy allows entities to add any role that follows the `[Prefix]-ROSA-Worker-Role` pattern to an instance profile. This policy grants necessary permissions to the installer to manage AWS resources that support ROSA cluster installation. **Permissions details** This policy includes the following permissions that allow the installer to complete the following tasks: + `ec2` — Run Amazon EC2 instances using AMIs hosted in AWS accounts owned and managed by Red Hat. Describe Amazon EC2 instances, volumes, and network resources associated with Amazon EC2 nodes. This permission is required so that the Kubernetes control plane can join instances to a cluster, and the cluster can evaluate its presence within Amazon VPC. Inspect Amazon EC2 Capacity Reservations to support the new Capacity Reservations feature in ROSA. Tag and delete tags on subnets using tag keys matching `"kubernetes.io/cluster/*"`. This is required to ensure that the load balancer used for cluster ingress is created only in applicable subnets and to manage Kubernetes cluster identification tags. + `elasticloadbalancing` — Add load balancers to target nodes on a cluster. Remove load balancers from target nodes on a cluster. This permission is required so that the Kubernetes control plane can dynamically provision load balancers requested by Kubernetes services and OpenShift application services. + `kms` — Read an AWS KMS key, create and manage grants to Amazon EC2, and return a unique symmetric data key for use outside of AWS KMS. This is required for the use of encrypted `etcd` data when `etcd` encryption is enabled at cluster creation. + `iam` — Validate IAM roles and policies. Dynamically provision and manage Amazon EC2 instance profiles relevant to the cluster. Add tags to an IAM instance profile by using the `iam:TagInstanceProfile` permission. Provide installer error messages when cluster installation fails due to a missing customer-specified cluster OIDC provider. + `route53` — Manage Route 53 resources needed to create clusters. + `servicequotas` — Evaluate service quotas required to create a cluster. + `sts` — Create temporary AWS STS credentials for ROSA components. Assume the credentials for cluster creation. + `secretsmanager` — Read a secret value to securely allow customer-managed OIDC configuration as part of cluster provisioning. To view the full JSON policy document, see [ROSAInstallerPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAInstallerPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSASharedVPCRoute53Policy You can attach `ROSASharedVPCRoute53Policy` to your IAM entities. You must attach this policy to an IAM role to allow a ROSA cluster to make calls to other AWS services in shared VPC environments. This policy allows the ROSA installer to configure Route 53 records. This policy is intended to be used on a shared VPC and provides a subset of Route 53 permissions tailored for shared VPC use cases. **Permissions details** This policy includes the following permissions that allow the ROSA installer to complete the following tasks: + `route53` — Read DNS zone information and existing DNS records to understand the current DNS configuration. Create, modify, and delete DNS records, but only for specific ROSA-related domain patterns including `.hypershift.local`, `.openshiftapps.com`, `.devshift.org`, `.openshiftusgov.com`, and `.devshiftusgov.com`. Add, modify, or remove tags on Route 53 resources for resource management and organization. + `tag` — Discover and list AWS resources based on their tags, which is useful for identifying resources managed by ROSA. To view more details about the policy, including the latest version of the JSON policy document, see [ROSASharedVPCRoute53Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASharedVPCRoute53Policy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSASharedVPCEndpointPolicy You can attach `ROSASharedVPCEndpointPolicy` to your IAM entities. You must attach this policy to an IAM role to allow a ROSA cluster to make calls to other AWS services in shared VPC environments. This policy allows the ROSA installer to configure VPC endpoints and security groups in shared VPC environments. **Permissions details** This policy includes the following permissions that allow the ROSA installer to complete the following tasks: + `ec2` — Read-only permissions to describe VPC-related resources including VPC endpoints, VPCs, and security groups to understand the network environment. Create, delete, and modify security groups with tag-based restrictions, enabling ROSA to create and manage security groups for cluster networking while restricting operations to only ROSA-tagged resources. Create, modify, and delete VPC endpoints with tag-based restrictions, allowing ROSA to create and manage VPC endpoints for private connectivity to AWS services in shared VPC environments. Apply tags to newly created VPC endpoints and security groups during creation for proper resource identification and management. To view more details about the policy, including the latest version of the JSON policy document, see [ROSASharedVPCEndpointPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASharedVPCEndpointPolicy.html) in the * AWS Managed Policy Reference Guide*. ## ROSA with HCP operator policies This section provides details about the operator policies that are required for ROSA with hosted control planes (HCP). You can attach these AWS managed policies to the operator roles needed to use ROSA with HCP. The permissions are required to allow OpenShift operators to manage ROSA with HCP cluster nodes. **Note** AWS managed policies are intended for use by ROSA with hosted control planes (HCP). ROSA classic clusters use customer managed IAM policies. For more information about ROSA classic policies, see [ROSA classic account policies](security-iam-rosa-classic-account-policies.md) and [ROSA classic operator policies](security-iam-rosa-classic-operator-policies.md). ### AWS managed policy: ROSAAmazonEBSCSIDriverOperatorPolicy You can attach `ROSAAmazonEBSCSIDriverOperatorPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants necessary permissions to the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA cluster. For more information about the operator, see [aws-ebs-csi-driver operator](https://github.com/openshift/aws-ebs-csi-driver-operator#aws-ebs-csi-driver-operator) in the OpenShift GitHub documentation. **Permissions details** This policy includes the following permissions that allow the Amazon EBS Driver Operator to complete the following tasks: + `ec2` — Create, modify, attach, detach, and delete Amazon EBS volumes that are attached to Amazon EC2 instances. Create and delete Amazon EBS volume snapshots and list Amazon EC2 instances, volumes, and snapshots. To view the full JSON policy document, see [ROSAAmazonEBSCSIDriverOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAAmazonEBSCSIDriverOperatorPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSAIngressOperatorPolicy You can attach `ROSAIngressOperatorPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the Ingress Operator to provision and manage load balancers and DNS configurations for ROSA clusters. The policy allows read access to tag values. The operator then filters the tag values for Route 53 resources to discover hosted zones. For more information about the operator, see [OpenShift Ingress Operator](https://github.com/openshift/cluster-ingress-operator#openshift-ingress-operator) in the OpenShift GitHub documentation. **Permissions details** This policy includes the following permissions that allow the Ingress Operator to complete the following tasks: + `elasticloadbalancing` — Describe the state of provisioned load balancers. + `route53` — List Route 53 hosted zones and edit records that manage the DNS controlled by the ROSA cluster. + `tag` — Manage tagged resources by using the `tag:GetResources` permission. To view the full JSON policy document, see [ROSAIngressOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAIngressOperatorPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSAImageRegistryOperatorPolicy You can attach `ROSAImageRegistryOperatorPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the Image Registry Operator to provision and manage resources for the ROSA in-cluster image registry and dependent services, including S3. This is required so that the operator can install and maintain the internal registry of a ROSA cluster. For more information about the operator, see [Image Registry Operator](https://github.com/openshift/cluster-image-registry-operator#image-registry-operator) in the OpenShift GitHub documentation. **Permissions details** This policy includes the following permissions that allow the Image Registry Operator to complete the following actions: + `s3` — Manage and evaluate Amazon S3 buckets as persistent storage for container image content and cluster metadata. To view the full JSON policy document, see [ROSAImageRegistryOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAImageRegistryOperatorPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSACloudNetworkConfigOperatorPolicy You can attach `ROSACloudNetworkConfigOperatorPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the Cloud Network Config Controller Operator to provision and manage networking resources for the ROSA cluster networking overlay. The operator uses these permissions to manage private IP addresses for Amazon EC2 instances as part of the ROSA cluster. For more information about the operator, see [Cloud-network-config-controller](https://github.com/openshift/cloud-network-config-controller#cloud-network-config-controller-cncc) in the OpenShift GitHub documentation. **Permissions details** This policy includes the following permissions that allow the Cloud Network Config Controller Operator to complete the following tasks: + `ec2` — Read, assign, and describe configurations for connecting Amazon EC2 instances, Amazon VPC subnets, and elastic network interfaces in a ROSA cluster. To view the full JSON policy document, see [ROSACloudNetworkConfigOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSACloudNetworkConfigOperatorPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSAKubeControllerPolicy You can attach `ROSAKubeControllerPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the kube controller to manage Amazon EC2, Elastic Load Balancing, and AWS KMS resources for a ROSA with hosted control planes cluster. For more information about this controller, see [Controller architecture](https://hypershift-docs.netlify.app/reference/controller-architecture/) in the OpenShift documentation. **Permissions details** This policy includes the following permissions that allow the kube controller to complete the following tasks: + `ec2` — Create, delete, and add tags to Amazon EC2 instance security groups. Add inbound rules to security groups. Describe Availability Zones, Amazon EC2 instances, route tables, security groups, VPCs, and subnets. + `elasticloadbalancing` — Create and manage load balancers and their policies. Create and manage load balancer listeners. Register and Deregister targets with target groups and manage target groups. Register and de-register Amazon EC2 instances with a load balancer, and add tags to load balancers. + `kms` — Retrieve detailed information about an AWS KMS key. This is required for the use of encrypted `etcd` data when `etcd` encryption is enabled at cluster creation. To view the full JSON policy document, see [ROSAKubeControllerPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAKubeControllerPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSANodePoolManagementPolicy You can attach `ROSANodePoolManagementPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the NodePool controller to describe, run, and terminate Amazon EC2 instances managed as worker nodes. This policy also grants permissions to allow for disk encryption of the worker node root volume using AWS KMS keys, to tag the elastic network interface that is attached to the worker node, and to access Amazon EC2 Capacity Reservations. For more information about this controller, see [Controller architecture](https://hypershift-docs.netlify.app/reference/controller-architecture/) in the OpenShift documentation. **Permissions details** This policy includes the following permissions that allow the NodePool controller to complete the following tasks: + `ec2` — Run Amazon EC2 instances using AMIs hosted in AWS accounts owned and managed by Red Hat. Manage EC2 lifecycles in the ROSA cluster. Dynamically create and integrate worker nodes with Elastic Load Balancing, Amazon VPC, Route 53, Amazon EBS, and Amazon EC2. Access and describe capacity reservations to support the Capacity Reservation feature in ROSA. + `iam` — Use Elastic Load Balancing via the service-linked role named `AWSServiceRoleForElasticLoadBalancing`. Assign roles to Amazon EC2 instance profiles. + `kms` — Read an AWS KMS key, create and manage grants to Amazon EC2, and return a unique symmetric data key for use outside of AWS KMS. This is required to allow for disk encryption of the worker node root volume. To view the full JSON policy document, see [ROSANodePoolManagementPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSANodePoolManagementPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSAKMSProviderPolicy You can attach `ROSAKMSProviderPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the built-in AWS Encryption Provider to manage AWS KMS keys that support `etcd` data encryption. This policy allows Amazon EC2 to use KMS keys that the AWS Encryption Provider provides to encrypt and decrypt `etcd` data. For more information about this provider, see [AWS Encryption Provider](https://github.com/kubernetes-sigs/aws-encryption-provider#aws-encryption-provider) in the Kubernetes GitHub documentation. **Permissions details** This policy includes the following permissions that allow the AWS Encryption Provider to complete the following tasks: + `kms` — Encrypt, decrypt, and retrieve an AWS KMS key. This is required for the use of encrypted `etcd` data when `etcd` encryption is enabled at cluster creation. To view the full JSON policy document, see [ROSAKMSProviderPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAKMSProviderPolicy.html) in the * AWS Managed Policy Reference Guide*. ### AWS managed policy: ROSAControlPlaneOperatorPolicy You can attach `ROSAControlPlaneOperatorPolicy` to your IAM entities. You must attach this policy to an operator IAM role to allow a ROSA with hosted control planes cluster to make calls to other AWS services. A unique set of operator roles is required for each cluster. This policy grants required permissions to the Control Plane Operator to manage Amazon EC2 and Route 53 resources for ROSA with hosted control planes clusters. For more information about this operator, see [Controller architecture](https://hypershift-docs.netlify.app/reference/controller-architecture/) in the OpenShift documentation. **Permissions details** This policy includes the following permissions that allow the Control Plane Operator to complete the following tasks: + `ec2` — Create and manage Amazon VPC endpoints. + `route53` — List and change Route 53 record sets and list hosted zones. + Added tags to RedHatManagedSecurityGroups: Allows the Control Plane Operator to tag Red Hat-managed security groups after creation. This is required for proper resource lifecycle management and cleanup of security groups associated with ROSA with HCP clusters. + Added security-group/\$1 to ManageVPCEndpointWithCondition: Fixes VPCE reconciliation failures during cluster upgrades. The operator needs permission to modify VPC endpoints that reference security groups. To view the full JSON policy document, see [ROSAControlPlaneOperatorPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAControlPlaneOperatorPolicy.html) in the * AWS Managed Policy Reference Guide*. ## ROSA updates to AWS managed policies View details about updates to AWS managed policies for ROSA since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the [Document history](doc-history.md) page. | Change | Description | Date | | --- | --- | --- | | ROSAControlPlaneOperatorPolicy — Policy updated | ROSA updated the policy to allow tagging of Red Hat-managed security groups for proper resource lifecycle management and to add security-group/\$1 to ManageVPCEndpointWithCondition to fix VPCE reconciliation failures during cluster upgrades. To learn more, see [AWS managed policy: ROSAControlPlaneOperatorPolicy](#security-iam-awsmanpol-rosacontrolplaneoperatorpolicy). | April 9, 2026 | | ROSAKubeControllerPolicy — Policy updated | ROSA updated the policy to clarify Elastic Load Balancing permissions for registering and deregistering targets with target groups. To learn more, see [AWS managed policy: ROSAKubeControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | March 5, 2026 | | ROSANodePoolManagementPolicy — Policy updated | ROSA updated the policy to add resource access for Amazon EC2 Capacity Reservations. This change allows the NodePool controller to access and describe Capacity Reservations for improved resource management. To learn more, see [AWS managed policy: ROSANodePoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | September 3, 2025 | | ROSASharedVPCEndpointPolicy — New policy added | ROSA added a new policy to allow the ROSA installer to configure VPC endpoints and security groups in shared VPC environments. This policy provides a subset of EC2 permissions tailored for shared VPC use cases. To learn more, see [AWS managed policy: ROSASharedVPCEndpointPolicy](#security-iam-awsmanpol-rosasharedvpcendpointpolicy). | August 7, 2025 | | ROSASharedVPCRoute53Policy — New policy added | ROSA added a new policy to allow the ROSA installer to configure Route 53 records in shared VPC environments. This policy provides a subset of Route 53 permissions tailored for shared VPC use cases. To learn more, see [AWS managed policy: ROSASharedVPCRoute53Policy](#security-iam-awsmanpol-rosasharedvpcroute53policy). | August 7, 2025 | | ROSAInstallerPolicy — Policy updated | ROSA updated the policy to allow the ROSA installer to inspect Amazon EC2 Capacity Reservations to support the new Capacity Reservations feature in ROSA. This update also allows the installer to delete tags on subnets using tag keys matching `"kubernetes.io/cluster/*"` for improved Kubernetes cluster tag management. To learn more, see [AWS managed policy: ROSAInstallerPolicy](#security-iam-awsmanpol-rosainstallerpolicy). | August 7, 2025 | | ROSAImageRegistryOperatorPolicy — Policy updated | ROSA updated the policy so that the permissions are scoped down to the S3 bucket resource level. This change satisfies ROSA storage requirements for both AWS Commercial and GovCloud Regions. To learn more, see [AWS managed policy: ROSAImageRegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | May 19, 2025 | | ROSANodePoolManagementPolicy — Policy updated | ROSA updated the policy to allow tagging of the elastic network interface that is attached to the worker node. To learn more, see [AWS managed policy: ROSANodePoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | May 5, 2025 | | ROSAImageRegistryOperatorPolicy — Policy updated | ROSA updated the policy to allow the Red Hat OpenShift Image Registry Operator to provision and manage Amazon S3 buckets and objects in AWS GovCloud Regions for use by the ROSA in-cluster image registry. This change satisfies ROSA storage requirements for AWS GovCloud Regions. To learn more, see [AWS managed policy: ROSAImageRegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | April 16, 2025 | | ROSAWorkerInstancePolicy — Policy updated | ROSA updated the policy to allow worker nodes to evaluate and get images from ROSA-managed ECR repositories that are necessary for cluster installation and worker node lifecycle management. To learn more, see [AWS managed policy: ROSAWorkerInstancePolicy](#security-iam-awsmanpol-rosaworkerinstancepolicy). | March 3, 2025 | | ROSANodePoolManagementPolicy — Policy updated | ROSA updated the policy to allow elastic network interfaces to be tagged similarly to EC2 instances only during ec2:RunInstances calls when the request includes the tag `red-hat-managed: true`. These permissions are necessary to support ROSA with HCP 4.17 clusters. To learn more, see [AWS managed policy: ROSANodePoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | February 24, 2025 | | ROSAAmazonEBSCSIDriverOperatorPolicy — Policy updated | ROSA updated the policy to support the new Amazon EBS snapshot authorization API. To learn more, see [AWS managed policy: ROSAAmazonEBSCSIDriverOperatorPolicy](#security-iam-awsmanpol-rosaamazonebscsidriveroperatorpolicy). | January 17, 2025 | | ROSANodePoolManagementPolicy — Policy updated | ROSA updated the policy to allow the ROSA node pool manager to describe DHCP option sets in order to set the proper private DNS names. To learn more, see [AWS managed policy: ROSANodePoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | May 2, 2024 | | ROSAInstallerPolicy — Policy updated | ROSA updated the policy to allow the ROSA installer to add tags to subnets using tag keys matching `"kubernetes.io/cluster/*"`. To learn more, see [AWS managed policy: ROSAInstallerPolicy](#security-iam-awsmanpol-rosainstallerpolicy). | April 24, 2024 | | ROSASRESupportPolicy — Policy updated | ROSA updated the policy to allow the SRE role to retrieve information on instance profiles that have been tagged by ROSA as `red-hat-managed`. To learn more, see [AWS managed policy: ROSASRESupportPolicy](#security-iam-awsmanpol-rosasresupportpolicy). | April 10, 2024 | | ROSAInstallerPolicy — Policy updated | ROSA updated the policy to allow the ROSA installer to validate that AWS managed policies for ROSA are attached to IAM roles used by ROSA. This update also allows the installer to identify whether customer managed policies have been attached to ROSA roles. To learn more, see [AWS managed policy: ROSAInstallerPolicy](#security-iam-awsmanpol-rosainstallerpolicy). | April 10, 2024 | | ROSAInstallerPolicy — Policy updated | ROSA updated the policy to allow the service to provide installer alert messages when cluster installation fails due to a missing customer-specified cluster OIDC provider. This update also allows the service to retrieve existing DNS name servers so that cluster provisioning operations are idempotent. To learn more, see [AWS managed policy: ROSAInstallerPolicy](#security-iam-awsmanpol-rosainstallerpolicy). | January 26, 2024 | | ROSASRESupportPolicy — Policy updated | ROSA updated the policy to allow the service to perform read operations on security groups using the DescribeSecurityGroups API. To learn more, see [AWS managed policy: ROSASRESupportPolicy](#security-iam-awsmanpol-rosasresupportpolicy). | January 22, 2024 | | ROSAImageRegistryOperatorPolicy — Policy updated | ROSA updated the policy to allow the Image Registry Operator to take actions on Amazon S3 buckets in Regions with 14-character names. To learn more, see [AWS managed policy: ROSAImageRegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | December 12, 2023 | | ROSAKubeControllerPolicy — Policy updated | ROSA updated the policy to allow the kube-controller-manager to describe Availability Zones, Amazon EC2 instances, route tables, security groups, VPCs, and subnets. To learn more, see [AWS managed policy: ROSAKubeControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | October 16, 2023 | | ROSAManageSubscription — Policy updated | ROSA updated the policy to add the ROSA with hosted control planes ProductId. To learn more, see [AWS managed policy: ROSAManageSubscription](#security-iam-awsmanpol-rosamanagesubscription). | August 1, 2023 | | ROSAKubeControllerPolicy — Policy updated | ROSA updated the policy to allow the kube-controller-manager to create Network Load Balancers as Kubernetes service load balancers. Network Load Balancers provide greater ability to handle volatile workloads and support static IP addresses for the load balancer. To learn more, see [AWS managed policy: ROSAKubeControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | July 13, 2023 | | ROSANodePoolManagementPolicy — New policy added | ROSA added a new policy to allow the NodePool controller to describe, run, and terminate Amazon EC2 instances managed as worker nodes. This policy also enables disk encryption of the worker node root volume using AWS KMS keys. To learn more, see [AWS managed policy: ROSANodePoolManagementPolicy](#security-iam-awsmanpol-rosanodepoolmanagementpolicy). | June 8, 2023 | | ROSAInstallerPolicy — New policy added | ROSA added a new policy to allow the installer to manage AWS resources that support cluster installation. To learn more, see [AWS managed policy: ROSAInstallerPolicy](#security-iam-awsmanpol-rosainstallerpolicy). | June 6, 2023 | | ROSASRESupportPolicy — New policy added | ROSA added a new policy to allow Red Hat SREs to directly observe, diagnose and support AWS resources associated with ROSA clusters, including the ability to change ROSA cluster node state. To learn more, see [AWS managed policy: ROSASRESupportPolicy](#security-iam-awsmanpol-rosasresupportpolicy). | June 1, 2023 | | ROSAKMSProviderPolicy — New policy added | ROSA added a new policy to allow the built-in AWS Encryption Provider to manage AWS KMS keys to support etcd data encryption. To learn more, see [AWS managed policy: ROSAKMSProviderPolicy](#security-iam-awsmanpol-rosakmsproviderpolicy). | April 27, 2023 | | ROSAKubeControllerPolicy — New policy added | ROSA added a new policy to allow the kube controller to manage Amazon EC2, Elastic Load Balancing, and AWS KMS resources for ROSA with hosted control planes clusters. To learn more, see [AWS managed policy: ROSAKubeControllerPolicy](#security-iam-awsmanpol-rosakubecontrollerpolicy). | April 27, 2023 | | ROSAImageRegistryOperatorPolicy — New policy added | ROSA added a new policy to allow the Image Registry Operator to provision and manage resources for the ROSA in-cluster image registry and dependent services, including S3. To learn more, see [AWS managed policy: ROSAImageRegistryOperatorPolicy](#security-iam-awsmanpol-rosaimageregistryoperatorpolicy). | April 27, 2023 | | ROSAControlPlaneOperatorPolicy — New policy added | ROSA added a new policy to allow the Control Plane Operator to manage Amazon EC2 and Route 53 resources for ROSA with hosted control planes clusters. To learn more, see [AWS managed policy: ROSAControlPlaneOperatorPolicy](#security-iam-awsmanpol-rosacontrolplaneoperatorpolicy). | April 24, 2023 | | ROSACloudNetworkConfigOperatorPolicy — New policy added | ROSA added a new policy to allow the Cloud Network Config Controller Operator to provision and manage networking resources for the ROSA cluster networking overlay. To learn more, see [AWS managed policy: ROSACloudNetworkConfigOperatorPolicy](#security-iam-awsmanpol-rosacloudnetworkconfigoperatorpolicy). | April 20, 2023 | | ROSAIngressOperatorPolicy — New policy added | ROSA added a new policy to allow the Ingress Operator to provision and manage load balancers and DNS configurations for ROSA clusters. To learn more, see [AWS managed policy: ROSAIngressOperatorPolicy](#security-iam-awsmanpol-rosaingressoperatorpolicy). | April 20, 2023 | | ROSAAmazonEBSCSIDriverOperatorPolicy — New policy added | ROSA added a new policy to allow the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA cluster. To learn more, see [AWS managed policy: ROSAAmazonEBSCSIDriverOperatorPolicy](#security-iam-awsmanpol-rosaamazonebscsidriveroperatorpolicy). | April 20, 2023 | | ROSAWorkerInstancePolicy — New policy added | ROSA added a new policy to allow the service to manage cluster resources. To learn more, see [AWS managed policy: ROSAWorkerInstancePolicy](#security-iam-awsmanpol-rosaworkerinstancepolicy). | April 20, 2023 | | ROSAManageSubscription — New policy added | ROSA added a new policy to grant the AWS Marketplace permissions required to manage the ROSA subscription. To learn more, see [AWS managed policy: ROSAManageSubscription](#security-iam-awsmanpol-rosamanagesubscription). | April 11, 2022 | | Red Hat OpenShift Service on AWS started tracking changes | Red Hat OpenShift Service on AWS started tracking changes for its AWS managed policies. | March 2, 2022 | # Troubleshooting ROSA identity and access Use the following information to help you diagnose and fix common issues that you might encounter when working with ROSA and IAM. ## AWS Organizations service control policy denies required AWS Marketplace permissions If your AWS Organizations service control policy (SCP) doesn’t allow the required AWS Marketplace subscription permissions when you attempt to enable ROSA, the following console error occurs. ``` An error occurred while enabling ROSA, because a service control policy (SCP) is denying required permissions. Contact your management account administrator, and consult the documentation for troubleshooting. ``` If you receive this error, then you must contact your administrator for assistance. Your administrator is the person that manages the accounts for your organization. Ask that person to do the following: 1. Configure the SCP to allow `aws-marketplace:Subscribe`, `aws-marketplace:Unsubscribe`, and `aws-marketplace:ViewSubscriptions` permissions. For more information, see [Updating an SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_create.html#update_policy) in the * AWS Organizations User Guide*. 1. Enable ROSA in the organization’s management account. 1. Share the ROSA subscription to member accounts that require access within the organization. For more information, see [Sharing subscriptions in an organization](https://docs.aws.amazon.com/marketplace/latest/buyerguide/organizations-sharing.html) in the * AWS Marketplace Buyer Guide*. ## User or role does not have the required AWS Marketplace permissions If your IAM principal doesn’t have the required AWS Marketplace subscription permissions when you attempt to enable ROSA, the following console error occurs. ``` An error occurred while enabling ROSA, because your user or role does not have the required permissions. ``` To resolve this issue, follow these steps: 1. Go to the [IAM console](https://console.aws.amazon.com/iam) and attach the AWS managed policy `ROSAManageSubscription` to your IAM identity. For more information, see [ROSAManageSubscription](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html) in the * AWS Managed Policy Reference Guide*. 1. Follow the procedure in [Enable ROSA and configure AWS prerequisites](set-up.md#enable-rosa). If you don’t have permission to view or update your permission set in IAM or you receive an error, then you must contact your administrator for assistance. Ask that person to attach `ROSAManageSubscription` to your IAM identity and follow the procedure in [Enable ROSA and configure AWS prerequisites](set-up.md#enable-rosa). When an administrator performs this action, it enables ROSA by updating the permission set for all IAM identities under the AWS account. ## Required AWS Marketplace permissions blocked by an administrator If your account administrator blocked the required AWS Marketplace subscription permissions, the following console error occurs when you attempt to enable ROSA. ``` An error occurred while enabling ROSA because required permissions have been blocked by an administrator. ROSAManageSubscription includes the permissions required to enable ROSA. Consult the documentation and try again. ``` If you receive this error, then you must contact your administrator for assistance. Ask that person to do the following: 1. Go to the [ROSA console](https://console.aws.amazon.com/rosa) and attach the AWS managed policy `ROSAManageSubscription` to your IAM identity. For more information, see [ROSAManageSubscription](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html) in the * AWS Managed Policy Reference Guide*. 1. Follow the procedure in [Enable ROSA and configure AWS prerequisites](set-up.md#enable-rosa) to enable ROSA. This procedure enables ROSA by updating the permission set for all IAM identities under the AWS account. ## Error creating load balancer: AccessDenied If you haven’t created a load balancer, the `AWSServiceRoleForElasticLoadBalacing` service-linked role may not exist in your account. The following error occurs if you attempt to create a ROSA cluster without the `AWSServiceRoleForElasticLoadBalacing` role in your account. ``` Error creating network Load Balancer: AccessDenied ``` To resolve this issue, follow these steps: 1. Check if your account has the `AWSServiceRoleForElasticLoadBalancing` role. ``` aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" ``` 1. If you don’t have this role, follow the instructions to create the role found in [Create the service-linked role](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/elb-service-linked-roles.html) in the * Elastic Load Balancing User Guide*. # Resilience in ROSA ## AWS global infrastructure resilience The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected through low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. ROSA provides customers with the option to run the Kubernetes control plane and data plane in a single AWS Availability Zone, or across multiple Availability Zones. While Single-AZ clusters can be useful for experimentation, customers are encouraged to run their workloads in more than one Availability Zone. This ensures that applications can withstand even a complete Availability Zone failure - a very rare event in itself. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](http://aws.amazon.com/about-aws/global-infrastructure/). ## ROSA cluster resilience The ROSA control plane consists of at least three OpenShift control plane nodes. Each control plane node is made up of an API server instance, an `etcd` instance, and controllers. In the event of a control plane node failure, all API requests are automatically routed to the other available nodes to ensure cluster availability. The ROSA data plane consists of at least two OpenShift infrastructure nodes and two OpenShift worker nodes. Infrastructure nodes run pods that support OpenShift cluster infrastructure components such as the default router, the built-in OpenShift registry, and the components for cluster metrics and monitoring. OpenShift worker nodes run end-user application pods. Red Hat site reliability engineers (SREs) fully manage the control plane and infrastructure nodes. Red Hat SREs proactively monitor the ROSA cluster, and are responsible for replacing any failed control plane nodes and infrastructure nodes. For more information, see [Overview of responsibilities for ROSA](rosa-responsibilities.md). **Important** Because ROSA is a managed service, Red Hat is responsible for managing the underlying AWS infrastructure that ROSA uses. Customers should not attempt to manually shut down the Amazon EC2 instances that ROSA uses from the AWS console or AWS CLI. This action can lead to customer data loss. If a worker node fails on the data plane, the control plane relocates unscheduled pods to the functioning worker node(s) until the failed node is recovered or replaced. Failed worker nodes can be replaced manually or automatically by enabling automatic scaling of machines in a cluster. For more information, see [Cluster autoscaling](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/cluster_administration/rosa-cluster-autoscaling) in the Red Hat documentation. ## Customer-deployed application resilience Although ROSA provides many protections to ensure high availability of the service, customers are responsible for building their deployed applications for high availability to protect workloads against downtime. For more information, see [About availability for ROSA](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/introduction_to_rosa/policies-and-service-definition#about-availability-for-rosa) in the Red Hat documentation. # Infrastructure security in ROSA As a managed service, Red Hat OpenShift Service on AWS is protected by the AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar — AWS Well-Architected Framework*. You use AWS published API calls to access ROSA through the AWS network. Clients must support the following: + Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3. + Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes. Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/) (AWS STS) to generate temporary security credentials to sign requests. ## Cluster network isolation Red Hat site reliability engineers (SREs) are responsible for the ongoing management and network security of the cluster and underlying application platform. For more information on Red Hat responsibilities for ROSA, see [Overview of responsibilities for ROSA](rosa-responsibilities.md). When you create a new cluster, ROSA provides the option of creating a public Kubernetes API server endpoint and application routes or a private Kubernetes API endpoint and application routes. This connection is used to communicate with your cluster (using OpenShift management tools such as the ROSA CLI and OpenShift CLI). A private connection allows all communication between your nodes and the API server to stay within your VPC. If you enable private access to the API server and application routes, you must use an existing VPC and AWS PrivateLink to connect the VPC to the OpenShift backend service. Kubernetes API server access is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes role-based access control (RBAC). For more information on Kubernetes RBAC, see [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in the Kubernetes documentation. ROSA allows you to create secured application routes using several types of TLS termination to serve certificates to the client. For more information, see [Secured routes](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/networking/configuring-routes#configuring-default-certificate) in the Red Hat documentation. If you create a ROSA cluster in an existing VPC, you specify the VPC subnets and Availability Zones for your cluster to use. You also define the CIDR ranges for the cluster network to use, and match these CIDR ranges to the VPC subnets. For more information, see [CIDR range definitions](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/networking/cidr-range-definitions) in the Red Hat documentation. For clusters that use the public API endpoint, ROSA requires that your VPC is configured with a public and private subnet for each Availability Zone that you want the cluster deployed into. For clusters that use the private API endpoint, only private subnets are required. If you are using an existing VPC, you can configure your ROSA clusters to use an HTTP or HTTPS proxy server during or after cluster creation to encrypt cluster web traffic, adding another layer of security for your data. When you enable a proxy, the core cluster components are denied direct access to the internet. The proxy does not deny internet access for user workloads. For more information, see [Configuring a cluster-wide proxy](https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/networking/configuring-a-cluster-wide-proxy) in the Red Hat documentation. ## Pod network isolation If you are a cluster administrator, you can define network policies at the pod level that restrict traffic to pods in your ROSA cluster.