OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

ROSA IAM role resources

edit

Red Hat OpenShift Service on AWS (ROSA) web UI requires that you have specific permissions on your AWS account that create a trust relationship to provide the end-user experience at OpenShift Cluster Manager and for the rosa command line interface (CLI).

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 AWS IAM roles required to use OpenShift Cluster Manager are:

  • ocm-role

  • user-role

Whether you manage your clusters using the ROSA CLI (rosa) or OpenShift Cluster Manager web UI, you must create the account-wide roles, known as account-roles in the ROSA CLI, by using the ROSA CLI. These account roles are necessary for your first cluster, and these roles can be used across multiple clusters. These required account roles are:

  • Worker-Role

  • Support-Role

  • Installer-Role

  • ControlPlane-Role

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.

For more information about creating these roles, see Account-wide IAM role and policy reference.

Cluster-specific Operator roles, known as operator-roles in the ROSA CLI, obtain the temporary permissions required to carry out cluster operations, such as managing back-end storage, ingress, and registry. These roles are required by the cluster that you create. These required Operator roles are:

  • <cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credentials

  • <cluster_name>-<hash>-openshift-cloud-network-config-controller-credentials

  • <cluster_name>-<hash>-openshift-machine-api-aws-cloud-credentials

  • <cluster_name>-<hash>-openshift-cloud-credential-operator-cloud-credentials

  • <cluster_name>-<hash>-openshift-image-registry-installer-cloud-credentials

  • <cluster_name>-<hash>-openshift-ingress-operator-cloud-credentials

For more information on creating these roles, see Cluster-specific Operator IAM role reference.

edit

About the ocm-role IAM resource

You must create the ocm-role IAM resource to enable a Red Hat organization of users to create Red Hat OpenShift Service on AWS (ROSA) 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.

  • 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.

    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 CLI (rosa), you can link your IAM resource when you create it.

"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::7333: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.

Additional resources

edit

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 Red Hat OpenShift Service on AWS (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

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

    $ rosa create ocm-role --admin

    This command allows you 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" in the Additional resources for more information.

Example output
I: Creating ocm role
? Role prefix: ManagedOpenShift (1)
? Enable admin capabilities for the OCM role (optional): No (2)
? Permissions boundary ARN (optional): (3)
? Role Path (optional): (4)
? Role creation mode: auto (5)
I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes (6)
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 (7)
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes (8)
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'
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.

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 the auto mode, you receive some different prompts to create the AWS roles.
6 The auto method asks if you want to create a specific ocm-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.
edit

About the user-role IAM role

You need to create a user-role IAM role per web UI user to enable those users to create ROSA 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.

"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.
edit

Creating a user-role IAM role

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

Prerequisites

  • You have an AWS account.

  • You have installed and configured the latest Red Hat OpenShift Service on AWS (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 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" in the Additional resources for more information.

Example output
I: Creating User role
? Role prefix: ManagedOpenShift (1)
? Permissions boundary ARN (optional): (2)
? Role Path (optional): (3)
? Role creation mode: auto (4)
I: Creating ocm user role using 'arn:aws:iam::2066:user'
? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes (5)
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 (6)
I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'
1 A prefix value for all of the created AWS resources. In this example, ManagedOpenShift prepends all of the AWS resources.
2 The Amazon Resource Name (ARN) of the policy to set permission boundaries.
3 Specify an IAM path for the user name.
4 Choose the method to create your AWS roles. 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.
5 The auto method asks if you want to create a specific user-role using your prefix.
6 Links the created role with your AWS organization.

If you unlink or delete your user-role IAM role prior to deleting your cluster, an error prevents you from deleting your cluster. You must create or relink this role to proceed with the deletion process. See Repairing a cluster that cannot be deleted for more information.
edit

AWS account association

Red Hat OpenShift Service on AWS (ROSA) cluster-provisioning tasks require linking ocm-role and user-role IAM roles to your AWS account using your Amazon Resource Name (ARN).

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 the necessary tasks in the AWS account.

edit

Linking your AWS account

You can link your AWS account to existing IAM roles by using the Red Hat OpenShift Service on AWS (ROSA) CLI, rosa.

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. See the "Additional resources" of this section for more information.

  • You have installed and configured the latest AWS (aws) and ROSA (rosa) CLIs on your installation host.

  • You have created your 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. From the CLI, link your ocm-role resource to your Red Hat organization by using your Amazon Resource Name (ARN):

    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 is visible for all users in the organization.

    		 
    $ rosa link ocm-role --role-arn <arn>
    Example output
    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. From the 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>
    Example output
    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>'
edit

Associating multiple AWS accounts with your Red Hat organization

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

With this feature, you can create clusters in different AWS regions by using multiple AWS profiles as 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 (aws) and ROSA (rosa) CLIs on your installation host.

  • You have created your ocm-role and user-role IAM roles.

Procedure

To associate an additional AWS account, first create a profile in your local AWS configuration. Then, associate the account with your Red Hat organization by creating the ocm-role, user, and account roles in the additional AWS account.

To create the roles in an additional region, specify the --profile <aws-profile> parameter when running the rosa create commands and replace <aws_profile> with the additional account profile name:

  • 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

If you do not specify a profile, the default AWS profile is used.
edit

Permission boundaries for the installer role

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. ROSA 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.

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 ROSA (classic architecture) installer to install an Red Hat OpenShift Service on AWS 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 ROSA (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 ROSA (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 ROSA. You can complete this with the AWS console or the AWS CLI. This example uses the AWS CLI and the following policy:

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"
                }
            }
        }
    ]
}

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 (rosa) CLI 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) and ROSA (rosa) CLIs on your workstation.

  • You have already prepared your ROSA 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.17/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"
    Example output
    {
    "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
    Example output
    PERMISSIONSBOUNDARY	arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy	Policy

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

    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": "*"
    }
  ]
}
    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": "*"
        }
    ]
}
edit

Additional resources