Opening required ports and IP addresses in your allowlist

Opening ports in a corporate allowlist

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, you must allow access to run ibmcloud, ibmcloud ks, and ibmcloud cr commands, kubectl commands, and calicoctl commands from your local system.

Opening ports in gateway appliance allowlists

If you have allowlists set up on the public network or private network in your IBM Cloud infrastructure account, such as a Virtual Router Appliance (Vyatta), you must open IP ranges, ports, and protocols to allow worker nodes to communicate with the master, with infrastructure resources, and with other IBM Cloud services.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>

Allowing the cluster to access resources through Calico network policies

Instead of setting up a gateway allowlist device, you can choose to use Calico network policies to act as a cluster allowlist on the public or private network. For more information, see the following topics.

• Isolating clusters on the public network.
• Isolating clusters on the private network.

Allowing traffic from your cluster in other services' allowlists or in on-premises allowlists

If you want to access services that run inside or outside IBM Cloud or on-premises and that are protected by an allowlist, you can add the IP addresses of your worker nodes in that allowlist to allow outbound network traffic to your cluster. For example, you might want to read data from an IBM Cloud database that is protected by an allowlist, or specify your worker node subnets in an on-premises allowlist to allow network traffic from your cluster.

1. Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.

2. Get the worker node subnets or the worker node IP addresses.

   • Worker node subnets: If you anticipate changing the number of worker nodes in your cluster frequently, such as if you enable the cluster autoscaler, you might not want to update your allowlist for each new worker node. Instead, you can add the VLAN subnets that the cluster uses. Keep in mind that the VLAN subnet might be shared by worker nodes in other clusters. Note that the primary public subnets that IBM Cloud Kubernetes Service provisions for your cluster come with 14 available IP addresses, and can be shared by other clusters on the same VLAN. When you have more than 14 worker nodes, another subnet is ordered, so the subnets that you need to allow can change. To reduce the frequency of change, create worker pools with worker node flavors of higher CPU and memory resources so that you don't need to add worker nodes as often.

     1. List the worker nodes in your cluster.

        ibmcloud ks worker ls --cluster <cluster_name_or_ID>
        

     2. From the output of the previous step, note all the unique network IDs (first three octets) of the Public IP for the worker nodes in your cluster. If you want to allow traffic from a private-only cluster, note the Private IP instead. In the following output, the unique network IDs are 169.xx.178 and 169.xx.210.

        ID                                                  Public IP        Private IP     Machine Type        State    Status   Zone    Version   
        kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w31   169.xx.178.101   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal10   1.31   
        kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w34   169.xx.178.102   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal10   1.31  
        kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w32   169.xx.210.101   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal12   1.31   
        kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w33   169.xx.210.102   10.xxx.xx.xxx   b3c.4x16.encrypted   normal   Ready    dal12   1.31  
        

     3. List the VLAN subnets for each unique network ID.

        ibmcloud sl subnet list | grep -e <networkID1> -e <networkID2>
        

        Example output

        ID        identifier       type                 network_space   datacenter   vlan_id   IPs   hardware   virtual_servers
        1234567   169.xx.210.xxx   ADDITIONAL_PRIMARY   PUBLIC          dal12        1122334   16    0          5   
        7654321   169.xx.178.xxx   ADDITIONAL_PRIMARY   PUBLIC          dal10        4332211   16    0          6    
        

     4. Retrieve the subnet address. In the output, find the number of IPs. Then, raise 2 to the power of n equal to the number of IPs. For example, if the number of IPs is 16, then 2 is raised to the power of 4 (n) to equal 16. Now get the subnet CIDR by subtracting the value of n from 32 bits. For example, when n equals 4, then the CIDR is 28 (from the equation 32 - 4 = 28). Combine the identifier mask with the CIDR value to get the full subnet address. In the previous output, the subnet addresses are:

        • 169.xx.210.xxx/28
        • 169.xx.178.xxx/28

   • Individual worker node IP addresses: If you have a small number of worker nodes that run only one app and don't need to scale, or if you want to add only one worker node, list all the worker nodes in your cluster and note the Public IP addresses. If your worker nodes are connected to a private network only and you want to connect to IBM Cloud services by using the private cloud service endpoint, note the Private IP addresses instead. Only these worker nodes are added. If you delete the worker nodes or add worker nodes to the cluster, you must update your allowlist accordingly.

     ibmcloud ks worker ls --cluster <cluster_name_or_ID>
     

3. Add the subnet CIDR or IP addresses to your service's allowlist for outbound traffic or your on-premises allowlist for inbound traffic.

4. Repeat these steps for each cluster that you want to allow traffic to or from.

Updating IAM allowlists for Kubernetes Service network zones

By default, all IP addresses can be used to log in to the IBM Cloud console and perform actions to manage your cluster, such as creating, updating, deleting or viewing credentials. In the IBM Cloud Identity and Access Management (IAM) console, you can create an allowlist by specifying which IP addresses have access, and all other IP addresses are restricted.

In your allowlist, you must also configure network zones in the IBM Cloud Kubernetes Service control plane for the region where your cluster is located so that IBM Cloud Kubernetes Service can create or access components such as Ingress ALBs

Before you begin, the following steps require you to change the IAM allowlist for the user whose credentials are used for the cluster's region and resource group infrastructure permissions. If you are the credentials owner, you can change your own IAM allowlist settings. If you are not the credentials owner, but you are assigned the Editor or Administrator IBM Cloud IAM platform access role for the User Management service, you can update the networks for the credentials owner.

1. Identify what user credentials are used for the cluster's region and resource group infrastructure permissions.

   1. Check the API key for a region and resource group of the cluster.

      ibmcloud ks api-key info --cluster <cluster_name_or_ID>
      

      Example output

      Getting information about the API key owner for cluster <cluster_name>...
      OK
      Name                Email   
      <user_name>         <name@email.com>
      

   2. Check if the infrastructure account for the region and resource group is manually set to use a different IBM Cloud infrastructure account.

      ibmcloud ks credential get --region <us-south>
      

      Example output if credentials are set to use a different account. In this case, the user's infrastructure credentials are used for the region and resource group that you targeted, even if a different user's credentials are stored in the API key that you retrieved in the previous step.

      OK
      Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>.
      

      Example output if credentials are not set to use a different account. In this case, the API key owner that you retrieved in the previous step has the infrastructure credentials that are used for the region and resource group.

      FAILED
      No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051)
      

2. Log in to the IBM Cloud console.

3. Create network zones that include the Kubernetes Service IPs for either all regions or just the regions that you have clusters in.

   1. In the account that the cluster is in, from the menu bar, click Manage > Context-based restrictions.

   2. Click Network zones > Create.

   3. For the Name, enter a descriptive name for the network zone, such as us-south-kubernetes-service-network-zone.

   4. Do not enter any values for the Allowed IP addresses and Allowed VPCs sections.

   5. In the Reference a service section, select Kubernetes Service and click +.

   6. For Locations, you can either leave the field empty so that all locations are used, which applies to clusters in other regions, or you can specify a single region.

   7. Click Next and review the selections.

   8. Click Create.

   9. Repeat for additional zones.

4. Add the network zone names to your IAM allowlist.

   1. From the menu bar, click Manage > Access (IAM), and select Users.

   2. Select the user that you found in step 1 from the list.

   3. From the User details page, go to the IP address restrictions section.

   4. Add the network zone names from the previous step. Example: us-south-kubernetes-service-network-zone

   5. Click Apply.