Skip to content

Latest commit

 

History

History
354 lines (293 loc) · 14.4 KB

cs_firewall.md

File metadata and controls

354 lines (293 loc) · 14.4 KB
copyright lastupdated
years
2014, 2018
2018-04-10

{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:download: .download}

Opening required ports and IP addresses in your firewall

{: #firewall}

Review these situations in which you might need to open specific ports and IP addresses in your firewalls for {{site.data.keyword.containerlong}}. {:shortdesc}


Running bx cs commands from behind a firewall

{: #firewall_bx}

If corporate network policies prevent access from your local system to public endpoints via proxies or firewalls, to run bx cs commands, you must allow TCP access for {{site.data.keyword.containerlong_notm}}. {:shortdesc}

  1. Allow access to containers.bluemix.net on port 443.

  2. Verify your connection. If access is configured correctly, ships are displayed in the output.

    curl https://containers.bluemix.net/v1/

    {: pre}

    Example output:

                                      )___(
                           _______/__/_
                  ___     /===========|   ___
 ____       __   [\\\]___/____________|__[///]   __
 \   \_____[\\]__/___________________________\__[//]___
  \                                                    |
   \                                                  /
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    {: screen}


Running kubectl commands from behind a firewall

{: #firewall_kubectl}

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

When a cluster is created, the port in the master URL is randomly assigned from within 20000-32767. You can either choose to open port range 20000-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 bx cs commands.

To allow access for a specific cluster:

  1. Log in to the {{site.data.keyword.Bluemix_notm}} CLI. Enter your {{site.data.keyword.Bluemix_notm}} credentials when prompted. If you have a federated account, include the --sso option.

    bx login [--sso]

    {: pre}

  2. Select the region that your cluster is in.

    bx cs region-set

    {: pre}

  3. Get the name of your cluster.

    bx cs clusters

    {: pre}

  4. Retrieve the Master URL for your cluster.

    bx cs cluster-get <cluster_name_or_id>

    {: pre}

    Example output:

    ...
Master URL:		https://169.46.7.238:31142
...

    {: screen}

  5. Allow access to the Master URL on the port, such as port 31142 in the previous example.

  6. Verify your connection.

    curl --insecure <master_URL>/version

    {: pre}

    Example command:

    curl --insecure https://169.46.7.238:31142/version

    {: pre}

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

    {: screen}

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


Running calicoctl commands from behind a firewall

{: #firewall_calicoctl}

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

Before you begin, allow access to run bx 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 calico-config -o yaml | grep etcd_endpoints

{: pre}

  1. Allow access for the Calico policies via the master URL IP address and the ETCD port.

Allowing the cluster to access infrastructure resources and other services

{: #firewall_outbound}

Let your cluster access infrastructure resources and services from behind a firewall, such as for {{site.data.keyword.containershort_notm}} regions, {{site.data.keyword.registrylong_notm}}, {{site.data.keyword.monitoringlong_notm}}, {{site.data.keyword.loganalysislong_notm}}, IBM Cloud infrastructure (SoftLayer) private IPs, and egress for persistent volume claims. {:shortdesc}

  1. Note the public IP address for all your worker nodes in the cluster.

    bx cs workers <cluster_name_or_id>

    {: pre}

  2. Allow outgoing network traffic from the source <each_worker_node_publicIP> to the destination TCP/UDP port range 20000-32767 and port 443, and the following IP addresses and network groups. If you have a corporate firewall that prevents your local machine from accessing public internet endpoints, do this step for both your source worker nodes and your local machine.

    • Important: You must allow outgoing traffic to port 443 for all of the locations within the region, to balance the load during the bootstrapping process. For example, if your cluster is in US South, you must allow traffic from port 443 to the IP addresses for all of the locations (dal10, dal12, and dal13).

Region Location IP address
AP North hkg02
seo01
sng01
tok02		 169.56.132.234
169.56.69.242
161.202.186.226
161.202.126.210
AP South mel01
syd01
syd04		 168.1.97.67
168.1.8.195
130.198.64.19, 130.198.66.34
EU Central ams03
fra02
mil01
par01		 169.50.169.110, 169.50.154.194
169.50.56.174
159.122.190.98
159.8.86.149, 159.8.98.170
UK South lon02
lon04		 159.122.242.78
158.175.65.170, 158.175.74.170, 158.175.76.2
US East mon01
tor01
wdc06
wdc07		 169.54.126.219
169.53.167.50
169.60.73.142
169.61.83.62
US South dal10
dal12
dal13
hou02
sao01		 169.47.234.18, 169.46.7.238
169.47.70.10
169.60.128.2
184.173.44.62
169.57.151.10

  1. Allow outgoing network traffic from the worker nodes to {{site.data.keyword.registrylong_notm}} regions:
    • TCP port 443 FROM <each_worker_node_publicIP> TO <registry_publicIP>
    • Replace <registry_publicIP> with the registry IP addresses to which you want to allow traffic. The global registry stores IBM-provided public images, and regional registries store your own private or public images.

{{site.data.keyword.containershort_notm}} region Registry address Registry IP address
Global registry across container regions registry.bluemix.net 169.60.72.144/28
169.61.76.176/28
AP North, AP South registry.au-syd.bluemix.net 168.1.45.160/27
168.1.139.32/27
EU Central registry.eu-de.bluemix.net 169.50.56.144/28
159.8.73.80/28
UK South registry.eu-gb.bluemix.net 159.8.188.160/27
169.50.153.64/27
US East, US South registry.ng.bluemix.net 169.55.39.112/28
169.46.9.0/27
169.55.211.0/27

  1. Optional: Allow outgoing network traffic from the worker nodes to {{site.data.keyword.monitoringlong_notm}} and {{site.data.keyword.loganalysislong_notm}} services:

    • TCP port 443, port 9095 FROM <each_worker_node_publicIP> TO <monitoring_publicIP>
    • Replace <monitoring_publicIP> with all of the addresses for the monitoring regions to which you want to allow traffic:

      Container region Monitoring address Monitoring IP addresses
      EU Central metrics.eu-de.bluemix.net 159.122.78.136/29
      UK South metrics.eu-gb.bluemix.net 169.50.196.136/29
      US East, US South, AP North metrics.ng.bluemix.net 169.47.204.128/29

- `TCP port 443, port 9091 FROM TO ` - Replace <logging_publicIP> with all of the addresses for the logging regions to which you want to allow traffic:

Container region Logging address Logging IP addresses
US East, US South ingest.logging.ng.bluemix.net 169.48.79.236
169.46.186.113
UK South ingest.logging.eu-gb.bluemix.net 169.50.115.113
EU Central ingest-eu-fra.logging.bluemix.net 158.177.88.43
159.122.87.107
AP South, AP North ingest-au-syd.logging.bluemix.net 130.198.76.125
168.1.209.20

  1. For private firewalls, allow the appropriate IBM Cloud infrastructure (SoftLayer) private IP ranges. Consult this link beginning with the Backend (private) Network section.

    • Add all of the locations within the regions that you are using.
    • Note that you must add the dal01 location (data center).
    • Open ports 80 and 443 to allow the cluster bootstrapping process.

  2. {: #pvc}To create persistent volume claims for data storage, allow egress access through your firewall for the IBM Cloud infrastructure (SoftLayer) IP addresses of the location (data center) that your cluster is in.

    • To find the location (data center) of your cluster, run bx cs clusters.
    • Allow access to the IP range for both the Frontend (public) network and Backend (private) Network.
    • Note that you must add the dal01 location (data center) for the Backend (private) Network.

Accessing NodePort, load balancer, and Ingress services from outside the cluster

{: #firewall_inbound}

You can allow incoming access to NodePort, load balancer, and Ingress services. {:shortdesc}

NodePort service
Open the port that you configured when you deployed the service to the public IP addresses for all of the worker nodes to allow traffic to. To find the port, run `kubectl get svc`. The port is in the 20000-32000 range.
LoadBalancer service
Open the port that you configured when you deployed the service to the load balancer service's public IP address.
Ingress
Open port 80 for HTTP or port 443 for HTTPS to the IP address for the Ingress application load balancer.