IBM Cloud Docs
Opening required ports and IP addresses in other network allowlists

Opening required ports and IP addresses in other network allowlists

Virtual Private Cloud

This allowlist information is specific to VPC clusters. For allowlist information for classic clusters, see Opening required ports and IP addresses in your allowlist for classic clusters.

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.

Running ibmcloud, ibmcloud ks, and ibmcloud cr commands from behind an allowlist

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run ibmcloud, ibmcloud ks and ibmcloud cr commands, you must allow TCP access for IBM Cloud, IBM Cloud Kubernetes Service, and IBM Cloud Container Registry.

  1. Allow access to cloud.ibm.com on port 443 in your allowlist.

  2. Verify your connection by logging in to IBM Cloud through this API endpoint.

    ibmcloud login -a https://cloud.ibm.com/

  3. Allow access to containers.cloud.ibm.com on port 443 in your allowlist.

  4. Verify your connection. If access is configured correctly, messages similar to the following are displayed in the output.

    curl https://containers.cloud.ibm.com/global/v1/versions

    Example output

    {"kubernetes":[{"major":1,"minor":19,"patch":16,"default":false,"end_of_service":""},{"major":1,"minor":20,"patch":13,"default":false,"end_of_service":""},{"major":1,"minor":21,"patch":7,"default":true,"end_of_service":""},{"major":1,"minor":22,"patch":4,"default":false,"end_of_service":""}],"openshift":[{"major":3,"minor":11,"patch":542,"default":false,"end_of_service":"2022-06-06T12:00:00+0000"},{"major":4,"minor":6,"patch":47,"default":false,"end_of_service":""},{"major":4,"minor":7,"patch":37,"default":false,"end_of_service":""},{"major":4,"minor":8,"patch":21,"default":true,"end_of_service":""}]}

  5. Allow access to the IBM Cloud Container Registry regions that you plan to use on port 443 in your allowlist. The global registry stores IBM-provided public images, and regional registries store your own private or public images. If your allowlist is IP-based, you can see which IP addresses are opened when you allow access to the IBM Cloud Container Registry regional service endpoints by reviewing this table.

  6. Verify your connection. The following is an example for the US East and US South regional registry. If access is configured correctly, a message of the day is returned in the output. Note that if there are no messages, a 204 is returned.

    curl -i https://us.icr.io/api/v1/messages

Running kubectl commands from behind an allowlist

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run kubectl commands, you must allow TCP access for the cluster.

When a cluster is created, the port in the service endpoint URLs is randomly assigned from within 30000-32767. You can either choose to open port range 30000-32767 for any cluster that might get created or you can choose to allow access for a specific existing cluster.

Before you begin, allow access to run ibmcloud ks commands.

To allow access for a specific cluster:

  1. Log in to the IBM Cloud CLI. Enter your IBM Cloud credentials when prompted. If you have a federated account, include the --sso option.

    ibmcloud login [--sso]

  2. If the cluster is in a resource group other than default, target that resource group. To see the resource group that each cluster belongs to, run ibmcloud ks cluster ls. Note: You must have at least the Viewer role for the resource group.

    ibmcloud target -g <resource_group_name>

  3. Get the name of your cluster.

    ibmcloud ks cluster ls

  4. Retrieve the service endpoint URLs for your cluster.

    • If only the Private Service Endpoint URL is populated, get this URL. Your authorized cluster users can access the master through this endpoint on the private network.
    • If both the Public Service Endpoint URL and Private Service Endpoint URL are populated, get both URLs. Your authorized cluster users can access the master through the public endpoint on the public network or the private endpoint on the private network.
    ibmcloud ks cluster get --cluster <cluster_name_or_ID>

    Example output

    ...
Public Service Endpoint URL:    https://c3.<region>.containers.cloud.ibm.com:30426
Private Service Endpoint URL:   https://c3-private.<region>.containers.cloud.ibm.com:31140
...

  5. Allow access to the service endpoint URLs and ports that you got in the previous step. If your allowlist is IP-based, you can see which IP addresses are opened when you allow access to the service endpoint URLs by reviewing this table.

  6. Verify your connection.

    • If the public cloud service endpoint is enabled:
      curl --insecure <public_service_endpoint_URL>/version
      Example command
      curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version
      Example output
      {
    "major": "1",
    "minor": "7+",
    "gitVersion": "v1.7.4-2+eb9172c211dc41",
    "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
    "gitTreeState": "clean",
    "buildDate": "2017-11-16T08:13:08Z",
    "goVersion": "go1.8.3",
    "compiler": "gc",
    "platform": "linux/amd64"
}
    • If only the private cloud service endpoint is enabled, you must be in your IBM Cloud private network or connect to the private network through a VPN connection to verify your connection to the master. Note: You must expose the master endpoint through a private load balancer so that users can access the master through a VPN or IBM Cloud® Direct Link connection. 
      curl --insecure <private_service_endpoint_URL>/version
      Example command
      curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version
      Example output
      {
    "major": "1",
    "minor": "7+",
    "gitVersion": "v1.7.4-2+eb9172c211dc41",
    "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534",
    "gitTreeState": "clean",
    "buildDate": "2017-11-16T08:13:08Z",
    "goVersion": "go1.8.3",
    "compiler": "gc",
    "platform": "linux/amd64"
}

  7. Optional: Repeat these steps for each cluster that you need to expose.

Running calicoctl commands from behind an allowlist

If corporate network policies prevent access from your local system to public endpoints via proxies or allowlists, to run calicoctl commands, you must allow TCP access for the Calico commands.

Before you begin, allow access to run ibmcloud commands and kubectl commands.

  1. Retrieve the IP address from the master URL that you used to allow the kubectl commands.

  2. Get the port for etcd.

    kubectl get cm -n kube-system cluster-info -o yaml | grep etcd_host

  3. Allow access for the Calico policies via the master URL IP address and the etcd port.

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

Allow your worker nodes to communicate with services that are protected by allowlists.

For example, you might have services that run inside or outside IBM Cloud, or services that run on-premises, that are protected by an allowlist. You want to permit incoming network traffic to those services from your cluster. In your service's allowlist, you must add the external IP addresses of the public gateways on your cluster's VPC subnets.

If you want to permit egress from your allowlist-protected services to your cluster, you must add your worker nodes' private IP addresses or your cluster's VPC subnet CIDRs in your service's allowlist. Note that because worker nodes in VPC clusters have only private IP addresses, connections into the VPC cluster worker nodes can only originate from systems that are connected to your IBM Cloud private network.

Before you begin

  1. Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.
  2. Install the infrastructure-service CLI plug-in. The prefix for running VPC infrastructure commands is ibmcloud is.
    ibmcloud plugin install infrastructure-service

Allowing ingress from a cluster to another service

To permit ingress from your cluster to another service, modify that service's allowlist or your on-premises allowlist.

  1. Get the Worker Zones and VPCs that your cluster is created in.

    ibmcloud ks cluster get -c <cluster>

    Example output

    ...
Worker Zones:                   us-south-1, us-south-2, us-south-3
Ingress Subdomain:              vpc-prod.us-south.containers.appdomain.cloud
Ingress Secret:                 vpc-prod
Creator:                        -
Public Service Endpoint URL:    https://c2.us-south.containers.cloud.ibm.com:20267
Private Service Endpoint URL:   https://c2.private.us-south.containers.cloud.ibm.com:20267
Pull Secrets:                   enabled in the default namespace
VPCs:                           ff537d43-a5a4-4b65-9627-17eddfa5237b
...

  2. For the worker zones and VPC that you found, ensure that you enabled a public gateway on the VPC subnets in each worker zone.

  3. List the public gateways for the subnets. In the output, for the zones and VPC that your cluster is in, note the gateway Floating IP addresses for the subnets.

    ibmcloud is public-gateways

    Example output

    ID                                     Name                                       Status      Floating IP      VPC              Zone
5d308ea5-9f32-43b3-aaae-194d5723a3e5   pgw-b9d45630-c053-11e9-b2f8-79328ce05e7e   available   169.XX.XXX.XX    test-vpc         us-south-1
f8b95e43-a408-4dc8-a489-ed649fc4cfec   pgw-18a3ebb0-b539-11e9-9838-f3f4efa02374   available   169.XX.XXX.XX    prod             us-south-1
2ba9a280-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   available   169.XX.XXX.XX    prod             us-south-2
057ddef6-631f-4b22-89eb-1e99982a54fa   pgw-64c5cae0-0be2-11ea-8f26-e1565e79a36c   available   52.XX.XXX.XXX    prod             us-south-3

  4. Add the public gateway IP addresses to your service's allowlist or your on-premises allowlist for inbound traffic.

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

Allowing egress to a cluster from another service

To permit egress to your cluster from another service, modify that service's allowlist or your on-premises allowlist.

  1. Get the worker node subnets or the worker node IP addresses.
    • Worker node subnet CIDRs: 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 VPC subnets that the cluster uses. Keep in mind that the VPC subnet might be shared by worker nodes in other clusters.
      1. Get the Worker Zones and VPCs that your cluster is created in.
        ibmcloud ks cluster get -c <cluster>
        Example output
        ...
Worker Zones:                   us-south-1, us-south-2, us-south-3
Ingress Subdomain:              vpc-prod.us-south.containers.appdomain.cloud
Ingress Secret:                 vpc-prod
Creator:                        -
Public Service Endpoint URL:    https://c2.us-south.containers.cloud.ibm.com:20267
Private Service Endpoint URL:   https://c2.private.us-south.containers.cloud.ibm.com:20267
Pull Secrets:                   enabled in the default namespace
VPCs:                           ff537d43-a5a4-4b65-9627-17eddfa5237b
...
      2. For the subnets in the zones and VPC that your cluster is in, note the Subnet CIDR.
        ibmcloud is subnets
        Example output
        ID                                     Name             Status      Subnet CIDR        Addresses   ACL                                                          Public Gateway                             VPC              Zone
5f5787a4-f560-471b-b6ce-20067ac93439   vpc-prod-dal1    available   10.240.0.0/24      183/256     allow-all-network-acl-ff537d43-a5a4-4b65-9627-17eddfa5237b   -                                          prod             us-south-1
e3c19786-1c54-4248-86ca-e60aab74ed62   vpc-prod-dal2    available   10.240.64.0/24     183/256     allow-all-network-acl-ff537d43-a5a4-4b65-9627-17eddfa5237b   -                                          prod             us-south-2
2930a068-51cc-4eca-807b-3f296d0891b4   vpc-prod-dal3    available   10.240.128.0/24    249/256     allow-all-network-acl-ff537d43-a5a4-4b65-9627-17eddfa5237b   -                                          prod             us-south-3
    • 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 Primary IP addresses. 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>
  2. Add the subnet CIDRs or individual worker node IP addresses to your service's allowlist or your on-premises allowlist for outbound traffic.
  3. Repeat these steps for each cluster that you want to allow traffic to or from.