Skip to main content

Cloud Platform IP Addresses

Wherever possible, we treat the network as a bearer, rather than a means to confer trust.

For this reason, explicitly allowing traffic from/to specific IP numbers is discouraged in general.

Inbound IP Filtering

Allowed client IP source ranges can be specified using the annotation. The value is a comma separated list of CIDRs, e.g.,

Kubernetes official documentation on allowing source ranges.

An example configuration using,

kind: Ingress
  annotations: |
          {"apiVersion":"","kind":"Ingress","metadata":{"annotations":{"":"nginx","":","},"name":"<my-ingress>","namespace":"<my-namespace>"},"spec":{"rules":[{"host":"","http":{"paths":[{"backend":{"serviceName":"<my-svc>","servicePort":3000},"path":"/"}]}}],"tls":[{"hosts":[""]}]}} nginx,
  creationTimestamp: 2019-03-21T14:26:31Z
  generation: 1
  name: <my-ingress>
  namespace: <my-namespace>
  - host:
      - path: /
      - backend:
          serviceName: <my-svc>
          servicePort: 3000
  - hosts:
    - hostname: <hostname>

Testing with the annotation set:

curl -v -H "Host:" <HOST-IP>

Will return a “403 forbidden” status

IP6 / IPv6

Currently, IPv6 is not supported for inbound IP filtering.

It should be possible to add IPv6 support to the platform, but nobody has asked for this, so we haven’t done it.

If this is something you need, please raise a support ticket explaining your need.

Outbound IP filtering

Please note that these numbers may change, and should not be relied upon for authentication/authorisation.

NAT Gateways

IP traffic from the Cloud Platform will originate from the IP numbers of one our NAT Gateways. We have one NAT Gateway in each of the three availability zones in which we host the Cloud Platform, and outbound traffic may originate from any of them.

Currently, these are the IPs from which traffic will appear to come:

Live-1 Cluster

There is no guarantee that the origin IPs of traffic from the cloud platform will remain the same.

If we plan to change them (e.g. if we migrate to another kubernetes cluster), we will provide as much notice as possible, via posts in the #cloud-platform-update slack channel.

However, in the event of a catastrophic failure where we have to rebuild the platform from scratch (easier than it sounds, since everything is defined in source code), we will not be able to give any warning.

This page was last reviewed on 11 May 2021. It needs to be reviewed again on 11 August 2021 .
This page was set to be reviewed before 11 August 2021. This might mean the content is out of date.