Questo contenuto non è disponibile nella lingua selezionata.
Chapter 6. Required IAM resources
Red Hat OpenShift Service on AWS uses the AWS Security Token Service (STS) to provide temporary, limited-permission credentials for your cluster. This means that before you deploy your cluster, you must create the following AWS Identity Access Management (IAM) resources:
- Specific account-wide IAM roles and policies that provide the STS permissions required for ROSA support, installation, and compute functionality. This includes account-wide Operator policies.
- Cluster-specific Operator IAM roles that permit the ROSA cluster Operators to carry out core OpenShift functionality.
- An OpenID Connect (OIDC) provider that the cluster Operators use to authenticate.
If you deploy and manage your cluster using OpenShift Cluster Manager, you must create the following additional resources:
- An OpenShift Cluster Manager IAM role to complete the installation on your cluster.
- A user role without any permissions to verify your AWS account identity.
This document provides reference information about the IAM resources that you must deploy when you create a ROSA with HCP cluster. It also includes the aws
CLI commands that are generated when you use manual
mode with the rosa create
command.
6.1. OpenShift Cluster Manager roles and permissions Copia collegamentoCollegamento copiato negli appunti!
If you create ROSA clusters by using OpenShift Cluster Manager, you must have the following AWS IAM roles linked to your AWS account to create and manage the clusters.
These AWS IAM roles are as follows:
-
The ROSA user role (
user-role
) is an AWS role used by Red Hat to verify the customer’s AWS identity. This role has no additional permissions, and the role has a trust relationship with the Red Hat installer account. An
ocm-role
resource grants the required permissions for installation of ROSA clusters in OpenShift Cluster Manager. You can apply basic or administrative permissions to theocm-role
resource. If you create an administrativeocm-role
resource, OpenShift Cluster Manager can create the needed AWS Operator roles and OpenID Connect (OIDC) provider. This IAM role also creates a trust relationship with the Red Hat installer account as well.NoteThe
ocm-role
IAM resource refers to the combination of the IAM role and the necessary policies created with it.
You must create this user role as well as an administrative ocm-role
resource, if you want to use the auto mode in OpenShift Cluster Manager to create your Operator role policies and OIDC provider.
6.1.1. Understanding the OpenShift Cluster Manager role Copia collegamentoCollegamento copiato negli appunti!
Creating ROSA clusters in OpenShift Cluster Manager require an ocm-role
IAM role. The basic ocm-role
IAM role permissions let you to perform cluster maintenance within OpenShift Cluster Manager. To automatically create the operator roles and OpenID Connect (OIDC) provider, you must add the --admin
option to the rosa create
command. This command creates an ocm-role
resource with additional permissions needed for administrative tasks.
This elevated IAM role allows OpenShift Cluster Manager to automatically create the cluster-specific Operator roles and OIDC provider during cluster creation. For more information about this automatic role and policy creation, see the "Methods of account-wide role creation" link in Additional resources.
6.1.1.1. Understanding the user role Copia collegamentoCollegamento copiato negli appunti!
In addition to an ocm-role
IAM role, you must create a user role so that Red Hat OpenShift Service on AWS can verify your AWS identity. This role has no permissions, and it is only used to create a trust relationship between the installer account and your ocm-role
resources.
The following tables show the associated basic and administrative permissions for the ocm-role
resource.
Resource | Description |
---|---|
| This permission allows the basic role to retrieve information about the specified OpenID Connect (OIDC) provider. |
| This permission allows the basic role to retrieve any information for a specified role. Some of the data returned include the role’s path, GUID, ARN, and the role’s trust policy that grants permission to assume the role. |
| This permission allows the basic role to list the roles within a path prefix. |
| This permission allows the basic role to list the tags on a specified role. |
| This permission allows the basic role to return information about all of the enabled regions on your account. |
| This permission allows the basic role to return information about all of your route tables. |
| This permission allows the basic role to return information about all of your subnets. |
| This permission allows the basic role to return information about all of your virtual private clouds (VPCs). |
| This permission allows the basic role to retrieve temporary security credentials to access AWS resources that are beyond its normal permissions. |
| This permission allows the basic role to retrieve temporary security credentials for users authenticated their account with a web identity provider. |
Resource | Description |
---|---|
| This permission allows the admin role to attach a specified policy to the desired IAM role. |
| This permission creates a resource that describes an identity provider, which supports OpenID Connect (OIDC). When you create an OIDC provider with this permission, this provider establishes a trust relationship between the provider and AWS. |
| This permission allows the admin role to create a role for your AWS account. |
| This permission allows the admin role to list any policies associated with your AWS account. |
| This permission allows the admin role to list any tags on a designated policy. |
| This permission allows the admin role to change the permissions boundary for a user based on a specified policy. |
| This permission allows the admin role to add tags to an IAM role. |
Creating an ocm-role IAM role
You create your ocm-role
IAM roles by using the command-line interface (CLI).
Prerequisites
- You have an AWS account.
- You have Red Hat Organization Administrator privileges in the OpenShift Cluster Manager organization.
- You have the permissions required to install AWS account-wide roles.
-
You have installed and configured the latest ROSA CLI,
rosa
, on your installation host.
Procedure
To create an ocm-role IAM role with basic privileges, run the following command:
rosa create ocm-role
$ rosa create ocm-role
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To create an ocm-role IAM role with admin privileges, run the following command:
rosa create ocm-role --admin
$ rosa create ocm-role --admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This command allows you to create the role by specifying specific attributes. The following example output shows the "auto mode" selected, which lets the ROSA CLI (
rosa
) create your Operator roles and policies. See "Methods of account-wide role creation" for more information.
Example output
- 1
- A prefix value for all of the created AWS resources. In this example,
ManagedOpenShift
prepends all of the AWS resources. - 2
- Choose if you want this role to have the additional admin permissions.Note
You do not see this prompt if you used the
--admin
option. - 3
- The Amazon Resource Name (ARN) of the policy to set permission boundaries.
- 4
- Specify an IAM path for the user name.
- 5
- Choose the method to create your AWS roles. Using
auto
, the ROSA CLI generates and links the roles and policies. In theauto
mode, you receive some different prompts to create the AWS roles. - 6
- The
auto
method asks if you want to create a specificocm-role
using your prefix. - 7
- Confirm that you want to associate your IAM role with your OpenShift Cluster Manager.
- 8
- Links the created role with your AWS organization.
AWS IAM roles link to your AWS account to create and manage the clusters.
6.2. Account-wide IAM role and policy reference Copia collegamentoCollegamento copiato negli appunti!
This section provides details about the account-wide IAM roles and policies that are required for ROSA deployments that use STS, including the Operator policies. It also includes the JSON files that define the policies.
The account-wide roles and policies are specific to an Red Hat OpenShift Service on AWS minor release version, for example Red Hat OpenShift Service on AWS 4, and are compatible with earlier versions. You can minimize the required STS resources by reusing the account-wide roles and policies for multiple clusters of the same minor version, regardless of their patch version.
6.2.1. Methods of account-wide role creation Copia collegamentoCollegamento copiato negli appunti!
You can create account-wide roles by using the Red Hat OpenShift Service on AWS (ROSA) CLI, rosa
, or the OpenShift Cluster Manager guided installation. You can create the roles manually or by using an automatic process that uses predefined names for these roles and policies.
Manual ocm-role resource creation
You can use the manual creation method if you have the necessary CLI access to create these roles on your system. You can run this option in your desired CLI tool or from OpenShift Cluster Manager. After you start the manual creation process, the CLI presents a series of commands for you to run that create the roles and link them to the needed policies.
Automatic ocm-role resource creation
If you created an ocm-role
resource with administrative permissions, you can use the automatic creation method from OpenShift Cluster Manager. The ROSA CLI does not require that you have this admin ocm-role
IAM resource to automatically create these roles and policies. Selecting this method creates the roles and policies that uses the default names.
If you use the ROSA guided installation on OpenShift Cluster Manager, you must have created an ocm-role
resource with administrative permissions in the first step of the guided cluster installation. Without this role, you cannot use the automatic Operator role and policy creation option, but you can still create the cluster and its roles and policies with the manual process.
Resource | Description |
---|---|
This policy streamlines permission setup by packaging necessary access rights, giving entities appropriate control over the ROSA subscription while preventing excessive permissions. |
Resource | Description |
---|---|
| An IAM role used by the ROSA installer. |
An IAM policy that provides the ROSA installer with the permissions required to complete cluster installation tasks. | |
| Grants the Red Hat installer temporary permission to act within your AWS account for the sole purpose of setting up a Red Hat OpenShift Service on AWS cluster. |
Example 6.1. sts_hcp_installer_permission_policy.json
Example 6.2. sts_hcp_installer_trust_policy.json
Resource | Description |
---|---|
| An IAM role used by the compute instances. |
An IAM policy that provides the ROSA compute instances with the permissions required to manage their components. | |
| Allows essential software on your worker nodes to securely connect and talk to the cluster’s control plane, which is managed remotely by Red Hat. |
Example 6.3. sts_hcp_worker_instance_permission_policy.json
Example 6.4. sts_hcp_worker_instance_trust_policy.json
Resource | Description |
---|---|
| An IAM role used by the Red Hat Site Reliability Engineering (SRE) support team. |
An IAM policy that provides the Red Hat SRE support team with the permissions required to support ROSA clusters. | |
| Provides a secure mechanism for authorized Red Hat Site Reliability Engineers (SREs) to perform diagnostic and support functions on the cluster. |
Example 6.5. sts_hcp_support_permission_policy.json
Example 6.6. sts_hcp_support_trust_policy.json
Resource | Description |
---|---|
| An IAM policy that grants permissions to the kube controller to manage Amazon EC2, Elastic Load Balancing, and AWS KMS resources. |
Example 6.7. openshift-hcp_kube-controller-manager-credentials-policy.json
Resource | Description |
---|---|
| An IAM policy that grants required permissions to the Control Plane Operator to manage Amazon EC2 and Route 53 resources. |
Example 6.8. openshift_hcp_control_plane_operator_credentials_policy.json
Resource | Description |
---|---|
| An IAM policy that 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, and to tag the elastic network interface that is attached to the worker node. |
Example 6.9. openshift_hcp_capa_controller_manager_credentials_policy.json
Resource | Description |
---|---|
| An IAM policy that 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. |
Example 6.10. openshift_hcp_image_registry_operator_permission_policy.json
Resource | Description |
---|---|
| An IAM policy that grants necessary permissions to the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA cluster. |
Example 6.11. openshift_hcp_cluster_csi_driver_ebs_operator_cloud_credentials_policy.json
Resource | Description |
---|---|
| An IAM policy that grants necessary permissions to the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA cluster. |
Example 6.12. openshift_hcp_cloud_network_config_cloud_credentials_permission_policy.json
Resource | Description |
---|---|
| An IAM policy that provides the ROSA Ingress Operator with the permissions required to manage external access to a cluster. |
Example 6.13. openshift_hcp_cluster_ingress_operator_cloud_credentials_policy.json
Resource | Description |
---|---|
| An IAM 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. |
Example 6.14. openshift_hcp_kms_provider_credential_policy.json
6.2.2. Account-wide IAM role and policy AWS CLI reference Copia collegamentoCollegamento copiato negli appunti!
This section lists the aws
CLI commands that the rosa
command generates in the terminal. You can run the command in either manual or automatic mode.
Using manual mode for account role creation
The manual role creation mode generates the aws
commands for you to review and run. The following command starts that process, where <openshift_version>
refers to your version of Red Hat OpenShift Service on AWS (ROSA), such as 4
.
rosa create account-roles --mode manual
$ rosa create account-roles --mode manual
The provided command examples include the ManagedOpenShift
prefix. The ManagedOpenShift
prefix is the default value, if you do not specify a custom prefix by using the --prefix
option.
Command output
Using auto mode for role creation
When you add the --mode auto
argument, the Red Hat OpenShift Service on AWS (ROSA) CLI, rosa
, creates your roles and policies. The following command starts that process:
rosa create account-roles --mode auto
$ rosa create account-roles --mode auto
The provided command examples include the ManagedOpenShift
prefix. The ManagedOpenShift
prefix is the default value, if you do not specify a custom prefix by using the --prefix
option.
Command output
6.3. Cluster-specific Operator IAM role reference Copia collegamentoCollegamento copiato negli appunti!
Operator roles are used to obtain the temporary permissions required to carry out cluster operations, such as managing back-end storage, cloud ingress controller, and external access to a cluster.
When you create the Operator roles, the account-wide Operator policies for the matching cluster version are attached to the roles. AWS managed Operator policies are versioned in AWS IAM. The latest version of an AWS managed policy is always used, so you do not need to manage or schedule upgrades for AWS managed policies used by ROSA with HCP.
If more than one matching policy is available in your account for an Operator role, an interactive list of options is provided when you create the role.
Role name | AWS Managed policy name | Role description |
---|---|---|
|
| An IAM role required by the cloud network config controller to manage cloud network credentials for a cluster. |
|
| An IAM role required by the ROSA Image Registry Operator to manage the OpenShift image registry storage in AWS S3 for a cluster. |
|
| An IAM role required for OpenShift management on HCP clusters. |
|
| An IAM role required for node management on HCP clusters. |
|
| An IAM role required control plane management on HCP clusters. |
|
| An IAM role required for OpenShift management on HCP clusters. |
|
| An IAM role required by the ROSA Ingress Operator to manage external access to a cluster. |
|
| An IAM role required by ROSA to manage back-end storage through the Container Storage Interface (CSI). |
6.3.1. Operator IAM role AWS CLI reference Copia collegamentoCollegamento copiato negli appunti!
This section lists the aws
CLI commands that are shown in the terminal when you run the following rosa
command using manual
mode:
rosa create operator-roles --mode manual --cluster <cluster_name>
$ rosa create operator-roles --mode manual --cluster <cluster_name>
When using manual
mode, the aws
commands are printed to the terminal for your review. After reviewing the aws
commands, you must run them manually. Alternatively, you can specify --mode auto
with the rosa create
command to run the aws
commands immediately.
Command output
The command examples provided in the table include Operator roles that use the ManagedOpenShift
prefix. If you defined a custom prefix when you created the account-wide roles and policies, including the Operator policies, you must reference it by using the --prefix <prefix_name>
option when you create the Operator roles.
6.3.2. About custom Operator IAM role prefixes Copia collegamentoCollegamento copiato negli appunti!
Each Red Hat OpenShift Service on AWS (ROSA) cluster requires cluster-specific Operator IAM roles.
By default, the Operator role names are prefixed with the cluster name and a random 4-digit hash. For example, the Ingress Cloud Credentials Operator IAM role for a cluster named mycluster
has the default name mycluster-<hash>-openshift-ingress-operator-cloud-credentials
, where <hash>
is a random 4-digit string.
This default naming convention enables you to easily identify the Operator IAM roles for a cluster in your AWS account.
When you create the Operator roles for a cluster, you can optionally specify a custom prefix to use instead of <cluster_name>-<hash>
. By using a custom prefix, you can prepend logical identifiers to your Operator role names to meet the requirements of your environment. For example, you might prefix the cluster name and the environment type, such as mycluster-dev
. In that example, the Ingress Cloud Credentials Operator role name with the custom prefix is mycluster-dev-openshift-ingress-operator-cloud-credenti
.
The role names are truncated to 64 characters.
6.4. Open ID Connect (OIDC) requirements for Operator authentication Copia collegamentoCollegamento copiato negli appunti!
For ROSA installations that use STS, you must create a cluster-specific OIDC provider that is used by the cluster Operators to authenticate or create your own OIDC configuration for your own OIDC provider.
6.4.1. Creating an OIDC provider using the CLI Copia collegamentoCollegamento copiato negli appunti!
You can create an OIDC provider that is hosted in your AWS account with the Red Hat OpenShift Service on AWS (ROSA) CLI, rosa
.
Prerequisites
- You have installed the latest version of the ROSA CLI.
Procedure
To create an OIDC provider, by using an unregistered or a registered OIDC configuration.
Unregistered OIDC configurations require you to create the OIDC provider through the cluster. Run the following to create the OIDC provider:
rosa create oidc-provider --mode manual --cluster <cluster_name>
$ rosa create oidc-provider --mode manual --cluster <cluster_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteWhen using
manual
mode, theaws
command is printed to the terminal for your review. After reviewing theaws
command, you must run it manually. Alternatively, you can specify--mode auto
with therosa create
command to run theaws
command immediately.Command output
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \ --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \
1 --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The URL used to reach the OpenID Connect (OIDC) identity provider after the cluster is created.
- 2
- The thumbprint is generated automatically when you run the
rosa create oidc-provider
command. For more information about using thumbprints with AWS Identity and Access Management (IAM) OIDC identity providers, see the AWS documentation.
Registered OIDC configurations use an OIDC configuration ID. Run the following command with your OIDC configuration ID:
rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
$ rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Command output
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.2. Creating an OpenID Connect Configuration Copia collegamentoCollegamento copiato negli appunti!
When using a cluster hosted by Red Hat, you can create a managed or unmanaged OpenID Connect (OIDC) configuration by using the Red Hat OpenShift Service on AWS (ROSA) CLI, rosa
. A managed OIDC configuration is stored within Red Hat’s AWS account, while a generated unmanaged OIDC configuration is stored within your AWS account. The OIDC configuration is registered to be used with OpenShift Cluster Manager. When creating an unmanaged OIDC configuration, the CLI provides the private key for you.
Creating an OpenID Connect configuration
When creating a Red Hat OpenShift Service on AWS cluster, you can create the OpenID Connect (OIDC) configuration before creating your cluster. This configuration is registered to be used with OpenShift Cluster Manager.
Prerequisites
- You have completed the AWS prerequisites for Red Hat OpenShift Service on AWS.
-
You have installed and configured the latest ROSA CLI,
rosa
, on your installation host.
Procedure
To create your OIDC configuration alongside the AWS resources, run the following command:
rosa create oidc-config --mode=auto --yes
$ rosa create oidc-config --mode=auto --yes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow This command returns the following information.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow When creating your cluster, you must supply the OIDC config ID. The CLI output provides this value for
--mode auto
, otherwise you must determine these values based onaws
CLI output for--mode manual
.Optional: you can save the OIDC configuration ID as a variable to use later. Run the following command to save the variable:
export OIDC_ID=<oidc_config_id>
$ export OIDC_ID=<oidc_config_id>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- In the example output above, the OIDC configuration ID is 13cdr6b.
View the value of the variable by running the following command:
echo $OIDC_ID
$ echo $OIDC_ID
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
13cdr6b
13cdr6b
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
You can list the possible OIDC configurations available for your clusters that are associated with your user organization. Run the following command:
rosa list oidc-config
$ rosa list oidc-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Parameter options for creating your own OpenID Connect configuration
The following options may be added to the rosa create oidc-config
command. All of these parameters are optional. Running the rosa create oidc-config
command without parameters creates an unmanaged OIDC configuration.
You are required to register the unmanaged OIDC configuration by posting a request to /oidc_configs
through OpenShift Cluster Manager. You receive an ID in the response. Use this ID to create a cluster.
raw-files
Allows you to provide raw files for the private RSA key. This key is named rosa-private-key-oidc-<random_label_of_length_4>.key
. You also receive a discovery document, named discovery-document-oidc-<random_label_of_length_4>.json
, and a JSON Web Key Set, named jwks-oidc-<random_label_of_length_4>.json
.
You use these files to set up the endpoint. This endpoint responds to /.well-known/openid-configuration
with the discovery document and on keys.json
with the JSON Web Key Set. The private key is stored in Amazon Web Services (AWS) Secrets Manager Service (SMS) as plaintext.
Example
rosa create oidc-config --raw-files
$ rosa create oidc-config --raw-files
mode
Allows you to specify the mode to create your OIDC configuration. With the manual
option, you receive AWS commands that set up the OIDC configuration in an S3 bucket. This option stores the private key in the Secrets Manager. With the manual
option, the OIDC Endpoint URL is the URL for the S3 bucket. You must retrieve the Secrets Manager ARN to register the OIDC configuration with OpenShift Cluster Manager.
You receive the same OIDC configuration and AWS resources as the manual
mode when using the auto
option. A significant difference between the two options is that when using the auto
option, ROSA calls AWS, so you do not need to take any further actions. The OIDC Endpoint URL is the URL for the S3 bucket. The CLI retrieves the Secrets Manager ARN, registers the OIDC configuration with OpenShift Cluster Manager, and reports the second rosa
command that the user can run to continue with the creation of the STS cluster.
Example
rosa create oidc-config --mode=<auto|manual>
$ rosa create oidc-config --mode=<auto|manual>
managed
Creates an OIDC configuration that is hosted under Red Hat’s AWS account. This command creates a private key that responds directly with an OIDC Config ID for you to use when creating the STS cluster.
Example
rosa create oidc-config --managed
$ rosa create oidc-config --managed
Example output
6.5. Minimum set of effective permissions for service control policies (SCP) Copia collegamentoCollegamento copiato negli appunti!
Service control policies (SCP) are a type of organization policy that manages permissions within your organization. SCPs ensure that accounts within your organization stay within your defined access control guidelines. These policies are maintained in AWS Organizations and control the services that are available within the attached AWS accounts. SCP management is the responsibility of the customer.
When using AWS Security Token Service (STS), you must ensure that the service control policy does not block the following resources:
-
ec2:{}
-
iam:{}
-
tag:*
Verify that your service control policy (SCP) does not restrict any of these required permissions.
Service | Actions | Effect | |
---|---|---|---|
Required | Amazon EC2 | All | Allow |
Amazon EC2 Auto Scaling | All | Allow | |
Amazon S3 | All | Allow | |
Identity And Access Management | All | Allow | |
Elastic Load Balancing | All | Allow | |
Elastic Load Balancing V2 | All | Allow | |
Amazon CloudWatch | All | Allow | |
Amazon CloudWatch Events | All | Allow | |
Amazon CloudWatch Logs | All | Allow | |
AWS EC2 Instance Connect | SendSerialConsoleSSHPublicKey | Allow | |
AWS Support | All | Allow | |
AWS Key Management Service | All | Allow | |
AWS Security Token Service | All | Allow | |
AWS Tiro | CreateQuery GetQueryAnswer GetQueryExplanation | Allow | |
AWS Marketplace | Subscribe Unsubscribe View Subscriptions | Allow | |
AWS Resource Tagging | All | Allow | |
AWS Route53 DNS | All | Allow | |
AWS Service Quotas | ListServices GetRequestedServiceQuotaChange GetServiceQuota RequestServiceQuotaIncrease ListServiceQuotas | Allow | |
Optional | AWS Billing | ViewAccount Viewbilling ViewUsage | Allow |
AWS Cost and Usage Report | All | Allow | |
AWS Cost Explorer Services | All | Allow |
6.6. Customer-managed policies Copia collegamentoCollegamento copiato negli appunti!
Red Hat OpenShift Service on AWS (ROSA) users are able to attach customer-managed policies to the IAM roles required to run and maintain ROSA clusters. This capability is not uncommon with AWS IAM roles. The ability to attach these policies to ROSA-specific IAM roles extends a ROSA cluster’s permission capabilities; for example, as a way to allow cluster components to access additional AWS resources that are otherwise not part of the ROSA-specific IAM policies.
To ensure that any critical customer applications that rely on customer-managed policies are not modified in any way during cluster or role upgrades, ROSA utilizes the ListAttachedRolesPolicies
permission to retrieve the list of permission policies from roles and the ListRolePolicies
permission to retrieve the list of policies from ROSA-specific roles. This information ensures that customer-managed policies are not impacted during cluster events, and allows Red Hat SREs to monitor both ROSA and customer-managed policies attached to ROSA-specific IAM roles, enhancing their ability to troubleshoot any cluster issues more effectively.
Attaching permission boundary policies to IAM roles that restrict ROSA-specific policies is not supported, as these policies could interrupt the functionality of the basic permissions necessary to successfully run and maintain your ROSA cluster. There are prepared permissions boundary policies for the ROSA (classic architecture) installer role. See the Additional resources section for more information.