Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Red Hat OpenShift Service on AWS classic architecture IAM role resources

You must create several role resources on your AWS account in order to create and manage a Red Hat OpenShift Service on AWS classic architecture cluster.

3.1. Overview of required roles
Copy link

To create and manage your Red Hat OpenShift Service on AWS classic architecture cluster, you must create several account-wide and cluster-wide roles. If you intend to use OpenShift Cluster Manager to create or manage your cluster, you need some additional roles.

To create and manage clusters

Several account-wide roles are required to create and manage Red Hat OpenShift Service on AWS classic architecture clusters. These roles only need to be created once per AWS account, and do not need to be created fresh for each cluster. One or more AWS managed policies are attached to each role to grant that role the required capabilities. You can specify your own prefix, or use the default prefix (ManagedOpenShift).

Note

Role names are limited to a maximum length of 64 characters in AWS IAM. When the user-specified prefix for a cluster is longer than 20 characters, the role name is truncated to observe this 64-character maximum in AWS IAM.

The following account-wide roles are required:

  • <prefix>-Worker-Role
  • <prefix>-Support-Role
  • <prefix>-Installer-Role
  • <prefix>-ControlPlane-Role
Note

Role creation does not request your AWS access or secret keys. AWS Security Token Service (STS) is used as the basis of this workflow. AWS STS uses temporary, limited-privilege credentials to provide authentication.

To use Operator-managed cluster capabilities

Some cluster capabilities, including several capabilities provided by default, are managed using Operators. Cluster-specific Operator roles (operator-roles in the ROSA CLI) are required to use these capabilities. These roles are used to obtain the temporary permissions required to carry out cluster operations such as managing back-end storage, ingress, and registry. Obtaining these permissions requires the configuration of an OpenID Connect (OIDC) provider, which connects to AWS Security Token Service (STS) to authenticate Operator access to AWS resources.

The following Operator roles are required for Red Hat OpenShift Service on AWS classic architecture clusters:

  • openshift-cluster-csi-drivers-ebs-cloud-credentials
  • openshift-cloud-network-config-controller-cloud-credentials
  • openshift-machine-api-aws-cloud-credentials
  • openshift-cloud-credential-operator-cloud-credentials
  • openshift-image-registry-installer-cloud-credentials
  • openshift-ingress-operator-cloud-credentials

When you create Operator roles using the rosa create operator-role command, the roles created are named using the pattern <cluster_name>-<hash>-<role_name>, for example, test-abc1-kube-system-control-plane-operator. When your cluster name is longer than 15 characters, the role name is truncated.

To use OpenShift Cluster Manager

The web user interface, OpenShift Cluster Manager, requires you to create additional roles in your AWS account to create a trust relationship between that AWS account and the OpenShift Cluster Manager.

This trust relationship is achieved through the creation and association of the ocm-role AWS IAM role. This role has a trust policy with the AWS installer that links your Red Hat account to your AWS account. In addition, you also need a user-role AWS IAM role for each web UI user, which serves to identify these users. This user-role AWS IAM role has no permissions.

The following AWS IAM roles are required to use OpenShift Cluster Manager:

  • ocm-role
  • user-role

3.2. About the ocm-role IAM resource
Copy link

You must create the ocm-role IAM resource to enable a Red Hat organization of users to create Red Hat OpenShift Service on AWS classic architecture clusters. Within the context of linking to AWS, a Red Hat organization is a single user within OpenShift Cluster Manager.

Some considerations for your ocm-role IAM resource are:

  • Only one ocm-role IAM role can be linked per Red Hat organization; however, you can have any number of ocm-role IAM roles per AWS account. The web UI requires that only one of these roles can be linked at a time.
  • Any user in a Red Hat organization may create and link an ocm-role IAM resource.

  • You must create an ocm-role before you can create a Red Hat OpenShift Service on AWS classic architecture cluster.

    Note

    If you are not using OpenShift Cluster Manager to create and manage clusters, you can use the --no-console profile to satisfy the ocm-role IAM resource requirement.

  • Only the Red Hat Organization Administrator can unlink an ocm-role IAM resource. This limitation is to protect other Red Hat organization members from disturbing the interface capabilities of other users.

    Note

    If you just created a Red Hat account that is not part of an existing organization, this account is also the Red Hat Organization Administrator.

  • See "Understanding the OpenShift Cluster Manager role" in the Additional resources of this section for a list of the AWS permissions policies for the basic and admin ocm-role IAM resources.

Using the ROSA command-line interface (CLI) (rosa), you can link your IAM resource when you create it.

Note

"Linking" or "associating" your IAM resources with your AWS account means creating a trust-policy with your ocm-role IAM role and the Red Hat OpenShift Cluster Manager AWS role. After creating and linking your IAM resource, you see a trust relationship from your ocm-role IAM resource in AWS with the arn:aws:iam::12345678abcd:role/RH-Managed-OpenShift-Installer resource.

After a Red Hat Organization Administrator has created and linked an ocm-role IAM resource, all organization members may want to create and link their own user-role IAM role. This IAM resource only needs to be created and linked only once per user. If another user in your Red Hat organization has already created and linked an ocm-role IAM resource, you need to ensure you have created and linked your own user-role IAM role.

3.2.1. ocm-role IAM resource profiles
Copy link

The ocm-role IAM resource exists with three profiles: no-console, standard, and admin. Each profile provides different levels of permissions and capabilities for managing Red Hat OpenShift Service on AWS classic architecture clusters.

No-console profile

The no-console profile provides the minimum permissions required for Red Hat OpenShift Service on AWS classic architecture to function with the ROSA command-line interface (CLI) (rosa). This profile is insufficient for creating clusters by using the OpenShift Cluster Manager console.

  • Available in ROSA CLI version 1.2.64 and higher
  • Allows cluster creation only through the ROSA CLI, Terraform, or CAPA
  • If you do not intend to use OpenShift Cluster Manager console for cluster creation, you can use the no-console profile and still comply with the requirement to create and link an ocm-role IAM resource

The no-console profile allows Red Hat OpenShift Service on AWS classic architecture to assume the ocm-role IAM role and fetch details about the role itself so that the service can validate if your ocm-role is configured correctly.

Standard profile
The standard profile is designed to support provisioning clusters through the OpenShift Cluster Manager console. This profile allows you to create Red Hat OpenShift Service on AWS classic architecture clusters through OpenShift Cluster Manager, but the standard profile does not automatically create your OIDC configs and Operator roles.
Admin profile

The admin profile is designed to provide support for automatically provisioning OIDC configs and Operator roles for your clusters.

  • Enabled using the --admin parameter with the rosa create ocm-role command
  • Supports auto mode configuration for Red Hat OpenShift Service on AWS (classic architecture) clusters
  • Provisions OIDC configuration and Operator roles on behalf of customers
  • Requires a wider set of permissions than the standard profile

3.2.2. Creating an ocm-role IAM role
Copy link

You create your ocm-role IAM roles by using the ROSA command-line interface (CLI) (rosa). If you want to create and manage clusters by using only the ROSA command-line interface (CLI) (rosa) and the OpenShift CLI (oc), you can use the --no-console profile for the ocm-role IAM resource. For more information about the ocm-role IAM resource permissions profile, see the Additional resources.

Important

You must create the ocm-role IAM role before you can create your Red Hat OpenShift Service on AWS classic architecture cluster.

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

  • Run one of the following commands to create the required ocm-role IAM resource:

    Important

    The process to change your ocm-role IAM resource profile requires you to unlink and delete the current ocm-role IAM resource and create a new one with the required profile.

    • To create an ocm-role IAM role with standard privileges, run the following command: 

      $ rosa create ocm-role

    • To create an ocm-role IAM role with admin privileges, run the following command:

      Important

      The admin profile supports "auto" mode configuration for Red Hat OpenShift Service on AWS classic architecture clusters which provisions OIDC Configuration and Operator roles automatically. To achieve this automatic flow, the profile has a wider set of permissions than the standard profile. 

      $ rosa create ocm-role --admin

      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. The following example shows what your creation flow might look like. 

      I: Creating ocm role
? Role prefix: ManagedOpenShift
? Enable admin capabilities for the OCM role (optional): No
? Permissions boundary ARN (optional):
? Role Path (optional):
? Role creation mode: auto
I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes
I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN  'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182'
I: Linking OCM role
? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'

      where:

      Role prefix
      A prefix value for all of the created AWS resources. In this example, ManagedOpenShift prepends all of the AWS resources.
      Enable admin capabilities for the OCM role (optional)

      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.

      Permissions boundary ARN (optional)
      The Amazon Resource Name (ARN) of the policy to set permission boundaries.
      Role Path (optional)
      Specify an IAM path for the user name.
      Role creation mode
      Choose the method to create your AWS roles. By using auto, the ROSA CLI generates and links the roles and policies. In the auto mode, you receive some different prompts to create the AWS roles.
      Create the 'ManagedOpenShift-OCM-Role-182' role?
      The auto method asks if you want to create a specific ocm-role by using your prefix.
      OCM Role ARN
      Confirm that you want to associate your IAM role with your OpenShift Cluster Manager.
      Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'?
      Links the created role with your AWS organization.

    • To create an ocm-role IAM role with the minimum required privileges, run the following command:

      Note

      While the no-console profile offers the minimum permissions policy that can still create Red Hat OpenShift Service on AWS classic architecture clusters, the permissions are insufficient if you want to use OpenShift Cluster Manager for cluster creation. 

      $ rosa create ocm-role --no-console

3.3. About the user-role IAM role
Copy link

You need to create a user-role IAM role per web UI user to enable those users to create Red Hat OpenShift Service on AWS classic architecture clusters.

Some considerations for your user-role IAM role are:

  • You only need one user-role IAM role per Red Hat user account, but your Red Hat organization can have many of these IAM resources.
  • Any user in a Red Hat organization may create and link an user-role IAM role.
  • There can be numerous user-role IAM roles per AWS account per Red Hat organization.
  • Red Hat uses the user-role IAM role to identify the user. This IAM resource has no AWS account permissions.
  • Your AWS account can have multiple user-role IAM roles, but you must link each IAM role to each user in your Red Hat organization. No user can have more than one linked user-role IAM role.
Note

"Linking" or "associating" your IAM resources with your AWS account means creating a trust-policy with your user-role IAM role and the Red Hat OpenShift Cluster Manager AWS role. After creating and linking this IAM resource, you see a trust relationship from your user-role IAM role in AWS with the arn:aws:iam::710019948333:role/RH-Managed-OpenShift-Installer resource.

3.4. Creating a user-role IAM role
Copy link

You can create your user-role IAM roles by using the ROSA command-line interface (CLI) (rosa).

Prerequisites

  • You have an AWS account.
  • You have installed and configured the latest ROSA CLI, rosa, on your installation host.

Procedure

  • To create a user-role IAM role with basic privileges, run the following command: 

    $ rosa create user-role

    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) to create your Operator roles and policies. See "Understanding the auto and manual deployment modes" for more information. The following example shows what your creation flow might look like. 

    I: Creating User role
? Role prefix: ManagedOpenShift
? Permissions boundary ARN (optional):
? Role Path (optional):
? Role creation mode: auto
I: Creating ocm user role using 'arn:aws:iam::2066:user'
? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes
I: Created role 'ManagedOpenShift-User.osdocs-Role' with ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role'
I: Linking User role
? User Role ARN: arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role
? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes
I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'

    where:

    Role prefix
    A prefix value for all of the created AWS resources. In this example, ManagedOpenShift prepends all of the AWS resources.
    Permissions boundary ARN (optional)
    The Amazon Resource Name (ARN) of the policy to set permission boundaries.
    Role Path (optional)
    Specify an IAM path for the user name.
    Role creation mode
    Choose the method to create your AWS roles. By using auto, the ROSA CLI generates and links the roles and policies. In the auto mode, you receive some different prompts to create the AWS roles.
    Create the 'ManagedOpenShift-User.osdocs-Role' role?
    The auto method asks if you want to create a specific user-role by using your prefix.
    Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'?
    Links the created role with your AWS organization.
    Important

    If you unlink or delete your user-role IAM role before deleting your cluster, an error prevents you from deleting your cluster. You must create or relink this role to proceed with the deletion process.

The following configuration details are required when using the OpenShift Cluster Manager or the CLI tools to manage your clusters.

3.5.1. AWS account association
Copy link

When you provision Red Hat OpenShift Service on AWS classic architecture using OpenShift Cluster Manager (console.redhat.com), you must associate the ocm-role and user-role IAM roles with your AWS account using your Amazon Resource Name (ARN). This association process is also known as account linking.

The ocm-role ARN is stored as a label in your Red Hat organization while the user-role ARN is stored as a label inside your Red Hat user account. Red Hat uses these ARN labels to confirm that the user is a valid account holder and that the correct permissions are available to perform provisioning tasks in the AWS account.

3.6. Associating your AWS account with IAM roles
Copy link

You can associate or link your AWS account with existing IAM roles by using the ROSA command-line interface (CLI) (rosa).

Prerequisites

  • You have an AWS account.
  • You have the permissions required to install AWS account-wide roles. See the "Additional resources" of this section for more information.
  • You have installed and configured the latest AWS CLI (aws) and ROSA CLI on your installation host.

  • You have created the ocm-role and user-role IAM roles, but have not yet linked them to your AWS account. You can check whether your IAM roles are already linked by running the following commands: 

    $ rosa list ocm-role
     
    $ rosa list user-role

    If Yes is displayed in the Linked column for both roles, you have already linked the roles to an AWS account.

Procedure

  1. In the ROSA CLI, link your ocm-role resource to your Red Hat organization by using your Amazon Resource Name (ARN):

    Note

    You must have Red Hat Organization Administrator privileges to run the rosa link command. After you link the ocm-role resource with your AWS account, it takes effect and is visible to all users in the organization. 

    $ rosa link ocm-role --role-arn <arn>

    For example: 

    I: Linking OCM role
? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'

  2. In the ROSA CLI, link your user-role resource to your Red Hat user account by using your Amazon Resource Name (ARN): 

    $ rosa link user-role --role-arn <arn>

    For example: 

    I: Linking User role
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'

You can associate multiple AWS accounts with your Red Hat organization. Associating multiple accounts lets you create Red Hat OpenShift Service on AWS classic architecture clusters on any of the associated AWS accounts from your Red Hat organization.

With this capability, you can create clusters on different AWS profiles according to characteristics that make sense for your business, for example, by using one AWS profile for each region to create region-bound environments.

Prerequisites

  • You have an AWS account.
  • You are using OpenShift Cluster Manager to create clusters.
  • You have the permissions required to install AWS account-wide roles.
  • You have installed and configured the latest AWS CLI (aws) and ROSA command-line interface (CLI) (rosa) on your installation host.
  • You have created the ocm-role and user-role IAM roles for Red Hat OpenShift Service on AWS classic architecture.

Procedure

  • To specify an AWS account profile when creating an OpenShift Cluster Manager role: 

    $ rosa create --profile <aws_profile> ocm-role

  • To specify an AWS account profile when creating a user role: 

    $ rosa create --profile <aws_profile> user-role

  • To specify an AWS account profile when creating the account roles: 

    $ rosa create --profile <aws_profile> account-roles
    Note

    If you do not specify a profile, the default AWS profile and its associated AWS region are used.

3.8. Permission boundaries for the installer role
Copy link

You can apply a policy as a permissions boundary on an installer role. You can use an AWS-managed policy or a customer-managed policy to set the boundary for an Amazon Web Services (AWS) Identity and Access Management (IAM) entity (user or role). The combination of policy and boundary policy limits the maximum permissions for the user or role. Red Hat OpenShift Service on AWS classic architecture includes a set of three prepared permission boundary policy files, with which you can restrict permissions for the installer role since changing the installer policy itself is not supported.

Note

This feature is only supported on Red Hat OpenShift Service on AWS (classic architecture) clusters.

The permission boundary policy files are as follows:

  • The Core boundary policy file contains the minimum permissions needed for Red Hat OpenShift Service on AWS classic architecture installer to install an Red Hat OpenShift Service on AWS classic architecture cluster. The installer does not have permissions to create a virtual private cloud (VPC) or PrivateLink (PL). A VPC needs to be provided.
  • The VPC boundary policy file contains the minimum permissions needed for Red Hat OpenShift Service on AWS classic architecture installer to create/manage the VPC. It does not include permissions for PL or core installation. If you need to install a cluster with enough permissions for the installer to install the cluster and create/manage the VPC, but you do not need to set up PL, then use the core and VPC boundary files together with the installer role.
  • The PrivateLink (PL) boundary policy file contains the minimum permissions needed for Red Hat OpenShift Service on AWS classic architecture installer to create the AWS PL with a cluster. It does not include permissions for VPC or core installation. Provide a pre-created VPC for all PL clusters during installation.

When using the permission boundary policy files, the following combinations apply:

  • No permission boundary policies means that the full installer policy permissions apply to your cluster.

  • Core only sets the most restricted permissions for the installer role. The VPC and PL permissions are not included in the Core only boundary policy.

    • Installer cannot create or manage the VPC or PL.
    • You must have a customer-provided VPC, and PrivateLink (PL) is not available.

  • Core + VPC sets the core and VPC permissions for the installer role.

    • Installer cannot create or manage the PL.
    • Assumes you are not using custom/BYO-VPC.
    • Assumes the installer will create and manage the VPC.

  • Core + PrivateLink (PL) means the installer can provision the PL infrastructure.

    • You must have a customer-provided VPC.
    • This is for a private cluster with PL.

This example procedure is applicable for an installer role and policy with the most restriction of permissions, using only the core installer permission boundary policy for Red Hat OpenShift Service on AWS classic architecture. You can complete this with the AWS console or the AWS CLI. This example uses the AWS CLI and the following policy:

The following example shows sts_installer_core_permission_boundary_policy.json: 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
		    "autoscaling:DescribeAutoScalingGroups",
		    "ec2:AllocateAddress",
		    "ec2:AssociateAddress",
		    "ec2:AttachNetworkInterface",
		    "ec2:AuthorizeSecurityGroupEgress",
		    "ec2:AuthorizeSecurityGroupIngress",
		    "ec2:CopyImage",
		    "ec2:CreateNetworkInterface",
		    "ec2:CreateSecurityGroup",
		    "ec2:CreateTags",
		    "ec2:CreateVolume",
		    "ec2:DeleteNetworkInterface",
		    "ec2:DeleteSecurityGroup",
		    "ec2:DeleteSnapshot",
		    "ec2:DeleteTags",
		    "ec2:DeleteVolume",
		    "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:GetConsoleOutput",
		    "ec2:GetEbsDefaultKmsKeyId",
		    "ec2:ModifyInstanceAttribute",
		    "ec2:ModifyNetworkInterfaceAttribute",
		    "ec2:ReleaseAddress",
		    "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: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",
		    "elasticloadbalancing:SetSecurityGroups",
		    "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:PassRole",
		    "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:GetAccelerateConfiguration",
		    "s3:GetBucketAcl",
		    "s3:GetBucketCORS",
		    "s3:GetBucketLocation",
		    "s3:GetBucketLogging",
		    "s3:GetBucketObjectLockConfiguration",
		    "s3:GetBucketPolicy",
		    "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:PutBucketPolicy",
		    "s3:PutBucketTagging",
		    "s3:PutEncryptionConfiguration",
		    "s3:PutObject",
		    "s3:PutObjectAcl",
		    "s3:PutObjectTagging",
		    "servicequotas:GetServiceQuota",
		    "servicequotas:ListAWSDefaultServiceQuotas",
		    "sts:AssumeRole",
		    "sts:AssumeRoleWithWebIdentity",
		    "sts:GetCallerIdentity",
		    "tag:GetResources",
		    "tag:UntagResources",
		    "kms:DescribeKey",
		    "cloudwatch:GetMetricData",
		    "ec2:CreateRoute",
		    "ec2:DeleteRoute",
		    "ec2:CreateVpcEndpoint",
		    "ec2:DeleteVpcEndpoints",
		    "ec2:CreateVpcEndpointServiceConfiguration",
		    "ec2:DeleteVpcEndpointServiceConfigurations",
		    "ec2:DescribeVpcEndpointServiceConfigurations",
		    "ec2:DescribeVpcEndpointServicePermissions",
		    "ec2:DescribeVpcEndpointServices",
		    "ec2:ModifyVpcEndpointServicePermissions"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/red-hat-managed": "true"
                }
            }
        }
    ]
}
Important

To use the permission boundaries, you will need to prepare the permission boundary policy and add it to your relevant installer role in AWS IAM. While the ROSA command-line interface (CLI) (rosa) offers a permission boundary function, it applies to all roles and not just the installer role, which means it does not work with the provided permission boundary policies (which are only for the installer role).

Prerequisites

  • You have an AWS account.
  • You have the permissions required to administer AWS roles and policies.
  • You have installed and configured the latest AWS (aws) CLI and ROSA CLI on your workstation.
  • You have already prepared your Red Hat OpenShift Service on AWS classic architecture account-wide roles, includes the installer role, and the corresponding policies. If these do not exist in your AWS account, see "Creating the account-wide STS roles and policies" in Additional resources.

Procedure

  1. Prepare the policy file by entering the following command in the ROSA CLI: 

    $ curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.21/sts_installer_core_permission_boundary_policy.json

  2. Create the policy in AWS and gather its Amazon Resource Name (ARN) by entering the following command: 

    $ aws iam create-policy \
--policy-name rosa-core-permissions-boundary-policy \
--policy-document file://./rosa-installer-core.json \
--description "ROSA installer core permission boundary policy, the minimum permission set, allows BYO-VPC, disallows PrivateLink"

    For example: 

    {
    "Policy": {
        "PolicyName": "rosa-core-permissions-boundary-policy",
        "PolicyId": "<Policy ID>",
        "Arn": "arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 0,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "CreateDate": "<CreateDate>",
        "UpdateDate": "<UpdateDate>"
    }
}

  3. Add the permission boundary policy to the installer role you want to restrict by entering the following command: 

    $ aws iam put-role-permissions-boundary \
--role-name ManagedOpenShift-Installer-Role \
--permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy

  4. Display the installer role to validate attached policies (including permissions boundary) by entering the following command in the ROSA CLI: 

    $ aws iam get-role --role-name ManagedOpenShift-Installer-Role \
--output text | grep PERMISSIONSBOUNDARY

    For example: 

    PERMISSIONSBOUNDARY	arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy	Policy

    For more examples of PL and VPC permission boundary policies see:

    The following example shows sts_installer_privatelink_permission_boundary_policy.json: 

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyVpcEndpointServiceConfiguration",
        "route53:ListHostedZonesByVPC",
        "route53:CreateVPCAssociationAuthorization",
        "route53:AssociateVPCWithHostedZone",
        "route53:DeleteVPCAssociationAuthorization",
        "route53:DisassociateVPCFromHostedZone",
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": "*"
    }
  ]
}

    The following example shows sts_installer_vpc_permission_boundary_policy.json: 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
		    "ec2:AssociateDhcpOptions",
		    "ec2:AssociateRouteTable",
		    "ec2:AttachInternetGateway",
		    "ec2:CreateDhcpOptions",
		    "ec2:CreateInternetGateway",
		    "ec2:CreateNatGateway",
		    "ec2:CreateRouteTable",
		    "ec2:CreateSubnet",
		    "ec2:CreateVpc",
		    "ec2:DeleteDhcpOptions",
		    "ec2:DeleteInternetGateway",
		    "ec2:DeleteNatGateway",
		    "ec2:DeleteRouteTable",
		    "ec2:DeleteSubnet",
		    "ec2:DeleteVpc",
		    "ec2:DetachInternetGateway",
		    "ec2:DisassociateRouteTable",
		    "ec2:ModifySubnetAttribute",
		    "ec2:ModifyVpcAttribute",
		    "ec2:ReplaceRouteTableAssociation"
            ],
            "Resource": "*"
        }
    ]
}
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top