Chapter 3. ROSA IAM role resources
Chapter 3. ROSA 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 (ROSA) cluster. 3.1. Overview of required roles To create and manage your Red Hat OpenShift Service on AWS 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 ROSA clusters. These roles only need to be created once per AWS account, and do not need to be created fresh for each cluster. You can specify your own prefix, or use the default prefix ( ManagedOpenShift ). 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 manage cluster features provided by Operators Cluster-specific Operator roles ( operator-roles in the ROSA CLI), obtain the temporary permissions required to carry out cluster operations for features provided by Operators, such as managing back-end storage, ingress, and registry. This requires the configuration of an OpenID Connect (OIDC) provider, which connects to AWS Security Token Service (STS) to authenticate Operator access to AWS resources. Operator roles are required for every cluster, as several Operators are used to provide cluster features by default. The following Operator roles are required: <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 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 Additional resources Account-wide IAM role and policy reference Cluster-specific Operator IAM role reference 3.2. 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. 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 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::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 Understanding the OpenShift Cluster Manager role 3.2.1. 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: USD rosa create ocm-role To create an ocm-role IAM role with admin privileges, run the following command: USD 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. 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. 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 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. Additional resources Methods of account-wide role creation 3.3. 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. 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.3.1. 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: USD 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. 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. Important 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. Additional resources Methods of account-wide role creation 3.4. AWS account association When you provision Red Hat OpenShift Service on AWS (ROSA) using OpenShift Cluster Manager, 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.4.1. Associating your AWS account with IAM roles You can associate or link your AWS account with existing IAM roles by using the Red Hat OpenShift Service on AWS (ROSA) 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 ( aws ) and ROSA ( rosa ) CLIs 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: USD rosa list ocm-role USD 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 From the 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 is visible for all users in the organization. USD 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>' From the CLI, link your user-role resource to your Red Hat user account by using your Amazon Resource Name (ARN): USD 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>' 3.4.2. 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: USD rosa create --profile <aws_profile> ocm-role To specify an AWS account profile when creating a user role: USD rosa create --profile <aws_profile> user-role To specify an AWS account profile when creating the account roles: USD rosa create --profile <aws_profile> account-roles Note If you do not specify a profile, the default AWS profile is used. 3.5. 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. 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 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: Example 3.1. 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 ( 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 Prepare the policy file by entering the following command in the rosa CLI: USD curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.18/sts_installer_core_permission_boundary_policy.json Create the policy in AWS and gather its Amazon Resource Name (ARN) by entering the following command: USD 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>" } } Add the permission boundary policy to the installer role you want to restrict by entering the following command: USD aws iam put-role-permissions-boundary \ --role-name ManagedOpenShift-Installer-Role \ --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy Display the installer role to validate attached policies (including permissions boundary) by entering the following command in the rosa CLI: USD 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: Example 3.2. 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": "*" } ] } Example 3.3. 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": "*" } ] } 3.6. Additional resources Permissions boundaries for IAM entities (AWS documentation) Creating the account-wide STS roles and policies Troubleshooting IAM roles Account-wide IAM role and policy reference
rosa create ocm-role rosa create ocm-role --admin 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>' rosa create user-role 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' rosa list ocm-role rosa list user-role rosa link ocm-role --role-arn <arn> 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>' rosa link user-role --role-arn <arn> 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>' rosa create --profile <aws_profile> ocm-role rosa create --profile <aws_profile> user-role rosa create --profile <aws_profile> account-roles { "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" } } } ] } curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.18/sts_installer_core_permission_boundary_policy.json 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" { "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>" } } aws iam put-role-permissions-boundary --role-name ManagedOpenShift-Installer-Role --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy aws iam get-role --role-name ManagedOpenShift-Installer-Role --output text | grep PERMISSIONSBOUNDARY PERMISSIONSBOUNDARY arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy Policy { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:ModifyVpcEndpointServiceConfiguration", "route53:ListHostedZonesByVPC", "route53:CreateVPCAssociationAuthorization", "route53:AssociateVPCWithHostedZone", "route53:DeleteVPCAssociationAuthorization", "route53:DisassociateVPCFromHostedZone", "route53:ChangeResourceRecordSets" ], "Resource": "*" } ] } { "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": "*" } ] }