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
×

Configuring an AWS account

Before you can install OpenShift Container Platform, you must configure an Amazon Web Services (AWS) account.

Configuring Route53

To install OpenShift Container Platform, the Amazon Web Services (AWS) account you use must have a dedicated public hosted zone in your Route53 service. This zone must be authoritative for the domain. The Route53 service provides cluster DNS resolution and name lookup for external connections to the cluster.

Procedure

  1. Identify your domain, or subdomain, and registrar. You can transfer an existing domain and registrar or obtain a new one through AWS or another source.

    If you purchase a new domain through AWS, it takes time for the relevant DNS changes to propagate. For more information about purchasing domains through AWS, see Registering Domain Names Using Amazon Route 53 in the AWS documentation.

  2. If you are using an existing domain and registrar, migrate its DNS to AWS. See Making Amazon Route 53 the DNS Service for an Existing Domain in the AWS documentation.

  3. Create a public hosted zone for your domain or subdomain. See Creating a Public Hosted Zone in the AWS documentation.

    Use an appropriate root domain, such as openshiftcorp.com, or subdomain, such as clusters.openshiftcorp.com.

  4. Extract the new authoritative name servers from the hosted zone records. See Getting the Name Servers for a Public Hosted Zone in the AWS documentation.

  5. Update the registrar records for the AWS Route53 name servers that your domain uses. For example, if you registered your domain to a Route53 service in a different accounts, see the following topic in the AWS documentation: Adding or Changing Name Servers or Glue Records.

  6. If you use a subdomain, follow your company’s procedures to add its delegation records to the parent domain.

AWS account limits

The OpenShift Container Platform cluster uses a number of Amazon Web Services (AWS) components, and the default Service Limits affect your ability to install OpenShift Container Platform clusters. If you use certain cluster configurations, deploy your cluster in certain AWS regions, or run multiple clusters from your account, you might need to request additional resources for you AWS account.

The following table summarizes the AWS components whose limits can impact your ability to install and run OpenShift Container Platform clusters.

Component Number of clusters available by default Default AWS limit Description

Instance Limits

Varies

Varies

By default, each cluster creates the following instances:

  • One bootstrap machine, which is removed after installation

  • Three master nodes

  • Three worker nodes

These instance type counts are within a new account’s default limit. To deploy more worker nodes, enable autoscaling, deploy large workloads, or use a different instance type, review your account limits to ensure that your cluster can deploy the machines that you need.

In most regions, the bootstrap and worker machines uses an m4.large machines and the master machines use m4.xlarge instances. In some regions, including all regions that do not support these instance types, m5.large and m5.xlarge instances are used instead.

Elastic IPs (EIPs)

0 to 1

5 EIPs per account

To provision the cluster in a highly available configuration, the installation program creates a public and private subnet for each availability zone within a region. Each private subnet requires a NAT Gateway, and each NAT gateway requires a separate elastic IP. Review the AWS region map to determine how many availability zones are in each region. To take advantage of the default high availability, install the cluster in a region with at least three availability zones. To install a cluster in a region with more than five availability zones, you must increase the EIP limit.

To use the us-east-1 region, you must increase the EIP limit for your account.

Virtual Private Clouds (VPCs)

5

5 VPCs per region

Each cluster creates its own VPC.

Elastic Load Balancing (ELB/NLB)

3

20 per region

By default, each cluster creates an internal and external network load balancers for the master API server and a single classic elastic load balancer for the router. Deploying more Kubernetes LoadBalancer Service objects will create additional load balancers.

NAT Gateways

5

5 per availability zone

The cluster deploys one NAT gateway in each availability zone.

Elastic Network Interfaces (ENIs)

At least 12

350 per region

The default installation creates 21 ENIs and an ENI for each availability zone in your region. For example, the us-east-1 region contains six availability zones, so a cluster that is deployed in that zone uses 27 ENIs. Review the AWS region map to determine how many availability zones are in each region.

Additional ENIs are created for additional machines and elastic load balancers that are created by cluster usage and deployed workloads.

VPC Gateway

20

20 per account

Each cluster creates a single VPC Gateway for S3 access.

S3 buckets

99

100 buckets per account

Because the installation process creates a temporary bucket and the registry component in each cluster creates a bucket, you can create only 99 OpenShift Container Platform clusters per AWS account.

Security Groups

250

2,500 per account

Each cluster creates 10 distinct security groups.

Required AWS permissions

When you attach the AdministratorAccess policy to the IAM user that you create, you grant that user all of the required permissions. To deploy an OpenShift Container Platform cluster, the IAM user requires the following permissions:

Required EC2 permissions for installation

  • ec2:AllocateAddress

  • ec2:AssociateAddress

  • ec2:AssociateDhcpOptions

  • ec2:AssociateRouteTable

  • ec2:AttachInternetGateway

  • ec2:AuthorizeSecurityGroupEgress

  • ec2:AuthorizeSecurityGroupIngress

  • ec2:CopyImage

  • ec2:CreateDhcpOptions

  • ec2:CreateInternetGateway

  • ec2:CreateNatGateway

  • ec2:CreateNetworkInterface

  • ec2:CreateRoute

  • ec2:CreateRouteTable

  • ec2:CreateSecurityGroup

  • ec2:CreateSubnet

  • ec2:CreateTags

  • ec2:CreateVpc

  • ec2:CreateVpcEndpoint

  • ec2:CreateVolume

  • ec2:DeleteSnapshot

  • ec2:DeregisterImage

  • ec2:DescribeAccountAttributes

  • ec2:DescribeAddresses

  • ec2:DescribeAvailabilityZones

  • ec2:DescribeDhcpOptions

  • ec2:DescribeImages

  • ec2:DescribeInstanceAttribute

  • ec2:DescribeInstanceCreditSpecifications

  • ec2:DescribeInstances

  • ec2:DescribeInternetGateways

  • ec2:DescribeKeyPairs

  • ec2:DescribeNatGateways

  • ec2:DescribeNetworkAcls

  • ec2:DescribePrefixLists

  • ec2:DescribeRegions

  • ec2:DescribeRouteTables

  • ec2:DescribeSecurityGroups

  • ec2:DescribeSubnets

  • ec2:DescribeTags

  • ec2:DescribeVpcEndpoints

  • ec2:DescribeVpcs

  • ec2:DescribeVpcAttribute

  • ec2:DescribeVolumes

  • ec2:DescribeVpcClassicLink

  • ec2:DescribeVpcClassicLinkDnsSupport

  • ec2:ModifyInstanceAttribute

  • ec2:ModifySubnetAttribute

  • ec2:ModifyVpcAttribute

  • ec2:RevokeSecurityGroupEgress

  • ec2:RunInstances

  • ec2:TerminateInstances

  • ec2:DeleteDhcpOptions

  • ec2:DeleteRoute

  • ec2:RevokeSecurityGroupIngress

  • ec2:DisassociateRouteTable

  • ec2:ReplaceRouteTableAssociation

  • ec2:DeleteRouteTable

  • ec2:DeleteSubnet

  • ec2:DescribeNetworkInterfaces

  • ec2:ModifyNetworkInterfaceAttribute

  • ec2:DeleteNatGateway

  • ec2:DeleteSecurityGroup

  • ec2:DetachInternetGateway

  • ec2:DeleteInternetGateway

  • ec2:ReleaseAddress

  • ec2:DeleteVpc

Required Elasticloadbalancing permissions for installation

  • elasticloadbalancing:AddTags

  • elasticloadbalancing:ApplySecurityGroupsToLoadBalancer

  • elasticloadbalancing:AttachLoadBalancerToSubnets

  • elasticloadbalancing:CreateListener

  • elasticloadbalancing:CreateLoadBalancer

  • elasticloadbalancing:CreateLoadBalancerListeners

  • elasticloadbalancing:CreateTargetGroup

  • elasticloadbalancing:ConfigureHealthCheck

  • elasticloadbalancing:DeleteLoadBalancer

  • elasticloadbalancing:DeregisterInstancesFromLoadBalancer

  • elasticloadbalancing:DeregisterTargets

  • elasticloadbalancing:DescribeInstanceHealth

  • elasticloadbalancing:DescribeListeners

  • elasticloadbalancing:DescribeLoadBalancers

  • elasticloadbalancing:DescribeLoadBalancerAttributes

  • elasticloadbalancing:DescribeTags

  • elasticloadbalancing:DescribeTargetGroupAttributes

  • elasticloadbalancing:DescribeTargetHealth

  • elasticloadbalancing:ModifyLoadBalancerAttributes

  • elasticloadbalancing:ModifyTargetGroup

  • elasticloadbalancing:ModifyTargetGroupAttributes

  • elasticloadbalancing:RegisterTargets

  • elasticloadbalancing:RegisterInstancesWithLoadBalancer

  • elasticloadbalancing:SetLoadBalancerPoliciesOfListener

Required IAM permissions for installation

  • iam:AddRoleToInstanceProfile

  • iam:CreateInstanceProfile

  • iam:CreateRole

  • iam:DeleteInstanceProfile

  • iam:DeleteRole

  • iam:DeleteRolePolicy

  • iam:GetInstanceProfile

  • iam:GetRole

  • iam:GetRolePolicy

  • iam:GetUser

  • iam:ListInstanceProfilesForRole

  • iam:ListRoles

  • iam:ListUsers

  • iam:PassRole

  • iam:PutRolePolicy

  • iam:RemoveRoleFromInstanceProfile

  • iam:SimulatePrincipalPolicy

  • iam:TagRole

Required Route53 permissions for installation

  • route53:ChangeResourceRecordSets

  • route53:ChangeTagsForResource

  • route53:GetChange

  • route53:GetHostedZone

  • route53:CreateHostedZone

  • route53:DeleteHostedZone

  • route53:ListHostedZones

  • route53:ListHostedZonesByName

  • route53:ListResourceRecordSets

  • route53:ListTagsForResource

  • route53:UpdateHostedZoneComment

Required S3 permissions for installation

  • s3:CreateBucket

  • s3:DeleteBucket

  • s3:GetAccelerateConfiguration

  • s3:GetBucketCors

  • s3:GetBucketLocation

  • s3:GetBucketLogging

  • s3:GetBucketObjectLockConfiguration

  • s3:GetBucketReplication

  • s3:GetBucketRequestPayment

  • s3:GetBucketTagging

  • s3:GetBucketVersioning

  • s3:GetBucketWebsite

  • s3:GetEncryptionConfiguration

  • s3:GetLifecycleConfiguration

  • s3:GetReplicationConfiguration

  • s3:ListBucket

  • s3:PutBucketAcl

  • s3:PutBucketTagging

  • s3:PutEncryptionConfiguration

S3 permissions that cluster Operators require

  • s3:PutObject

  • s3:PutObjectAcl

  • s3:PutObjectTagging

  • s3:GetObject

  • s3:GetObjectAcl

  • s3:GetObjectTagging

  • s3:GetObjectVersion

  • s3:DeleteObject

All additional permissions that are required to uninstall a cluster

  • autoscaling:DescribeAutoScalingGroups

  • ec2:DeleteNetworkInterface

  • ec2:DeleteVolume

  • ec2:DeleteVpcEndpoints

  • elasticloadbalancing:DescribeTargetGroups

  • elasticloadbalancing:DeleteTargetGroup

  • iam:ListInstanceProfiles

  • iam:ListRolePolicies

  • iam:ListUserPolicies

  • tag:GetResources

Additional IAM and S3 permissions that are required to create manifests

  • iam:CreateAccessKey

  • iam:CreateUser

  • iam:DeleteAccessKey

  • iam:DeleteUser

  • iam:DeleteUserPolicy

  • iam:GetUserPolicy

  • iam:ListAccessKeys

  • iam:PutUserPolicy

  • iam:TagUser

  • iam:GetUserPolicy

  • iam:ListAccessKeys

  • s3:PutBucketPublicAccessBlock

  • s3:GetBucketPublicAccessBlock

  • s3:PutLifecycleConfiguration

  • s3:HeadBucket

  • s3:ListBucketMultipartUploads

  • s3:AbortMultipartUpload

Creating an IAM user

Each Amazon Web Services (AWS) account contains a root user account that is based on the email address you used to create the account. This is a highly-privileged account, and it is recommended to use it for only initial account and billing configuration, creating an initial set of users, and securing the account.

Before you install OpenShift Container Platform, create a secondary IAM administrative user. As you complete the Creating an IAM User in Your AWS Account procedure in the AWS documentation, set the following options:

Procedure

  1. Specify the IAM user name and select Programmatic access.

  2. Attach the AdministratorAccess policy to ensure that the account has sufficient permission to create the cluster. This policy provides the cluster with the ability to grant credentials to each OpenShift Container Platform component. The cluster grants the components only the credentials that they require.

    While it is possible to create a policy that grants the all of the required AWS permissions and attach it to the user, this is not the preferred option. The cluster will not have the ability to grant additional credentials to individual components, so the same credentials are used by all components.

  3. Optional: Add metadata to the user by attaching tags.

  4. Confirm that the user name that you specified is granted the AdministratorAccess policy.

  5. Record the access key ID and secret access key values. You must use these values when you configure your local machine to run the installation program.

    You cannot use a temporary session token that you generated while using a multi-factor authentication device to authenticate to AWS when you deploy a cluster. The cluster continues to use your current AWS credentials to create AWS resources for the entire life of the cluster, so you must use key-based, long-lived credentials.

Supported AWS regions

You can deploy an OpenShift Container Platform cluster to the following regions:

  • ap-northeast-1 (Tokyo)

  • ap-northeast-2 (Seoul)

  • ap-south-1 (Mumbai)

  • ap-southeast-1 (Singapore)

  • ap-southeast-2 (Sydney)

  • ca-central-1 (Central)

  • eu-central-1 (Frankfurt)

  • eu-north-1 (Stockholm)

  • eu-west-1 (Ireland)

  • eu-west-2 (London)

  • eu-west-3 (Paris)

  • sa-east-1 (São Paulo)

  • us-east-1 (N. Virginia)

  • us-east-2 (Ohio)

  • us-west-1 (N. California)

  • us-west-2 (Oregon)

Next steps