Inbound network access is only available for workloads of types serverless, standard, and stateful. For other workload types, only outbound firewall settings are relevant.

​
External

The external firewall is used to control Internet traffic to/from a workload.
YAML
spec:
  firewallConfig:
    external:
      inboundAllowCIDR:
        - 1.2.3.0/24
      outboundAllowCIDR:
        - 1.2.3.0/24
      outboundAllowHostname:
        - example.com
      outboundAllowPort:
        - protocol: http
          number: 80
      inboundBlockedCIDR:
        - 1.2.3.4/32
      outboundBlockedCIDR:
        - 1.2.3.4/32
      http:
        inboundHeaderFilter:
          - key: foo
            allowedValues:
              - bar.*

​
Inbound Requests

  • By default, all inbound requests are disabled.
  • Access is granted by explicitly adding one or more IPv4 / IPv6 / CIDR addresses or allowing all addresses.
  • Using the UI:
    • Multiple address can entered within the textbox by delimiting each address with either a comma or space.
    • An import file can be uploaded containing each address on its own line or delimited with either a comma or space.
The CIDR address 0.0.0.0/0 allows full inbound access from the public Internet.

​
Outbound Requests

  • By default, all outbound requests are disabled.
  • By default, or by specifying NO outbound ports, all are ALLOWED.
  • When outbound ports are specified, only traffic to those ports will be allowed.
  • Access is granted by explicitly adding one or more IPv4 / IPv6 / CIDR addresses or public hostnames or allowing all addresses / hostnames.
    • When using a hostname, only ports 80, 443, and 445 will be reachable. To allow all ports, enable all outbound requests.
    • When using a IP or CIDR, all ports will be reachable.
  • The IP/CIDR addresses takes precedence over hostnames.
  • Using the UI:
    • Multiple address can entered within the textbox by delimiting each address with either a comma or space.
    • An import file can be uploaded containing each address on its own line or delimited with either a comma or space.
The CIDR address 0.0.0.0/0 allows full outbound access to the public Internet.

​
Blocked Addresses

All addresses specified will be blocked from outbound/inbound requests to/from this workload
YAML
spec:
  firewallConfig:
    external:
      inboundBlockedCIDR:
        - 1.2.3.4/32
      outboundBlockedCIDR:
        - 1.2.3.4/32
  • Blocking an address has the same effect as not including it in the allow CIDR list

​
Inbound HTTP Header Filter

Using the inboundHeaderFilter field, you can filter out requests that do not meet certain http header criteria. You can permit permit headers that contain a specific header/value pair or deny them. This can be used in conjunction with geo-headers, to allow/deny requests originating from specific locations. If multiple allow or deny filters are specified, the resulting operation will be triggered if ANY value is matched. It does not have to match all of them.
The values are regular expressions (RE2)

​
Examples

Only allows requests with the foo header, with any value:
YAML
spec:
  firewallConfig:
    http:
      inboundHeaderFilter:
        - key: foo
          allowedValues:
            - .*
Allows all requests except those with the foo=bar header
YAML
spec:
  firewallConfig:
    http:
      inboundHeaderFilter:
        - key: foo
          blockedValues:
            - ^bar$
Since the values are regular expressions, ^ must be put at the start and $ at the end to match a whole string (and not also match strings like "barbell")

​
Geo Filtering

The inbound header filter can be configured to be used in conjunction with geo headers. Here is an example where we only allow requests coming from the United States
YAML
spec:
  loadBalancer:
    geoLocation:
      enabled: true
      headers:
        country: x-country
  firewallConfig:
    http:
      inboundHeaderFilter:
        - key: x-country
          allowedValues:
            - United States

​
Internal

The internal firewall is used to control access between other workloads within an org. Only the ports listed in the workload containers array will be made accessible to other workloads. This example allows workloads running in the same GVC to access this workload.
YAML
spec:
  firewallConfig:
    internal:
      inboundAllowType: same-gvc
This example allows a few specific workloads across the org to access this workload.
YAML
spec:
  firewallConfig:
    internal:
      inboundAllowType: workload-list
      inboundAllowWorkload:
        - //gvc/amazingapp/workload/users
        - //gvc/bestapp/workload/orders
This example allows a few specific workloads across the org and all workloads in the same GVC to access this workload.
YAML
spec:
  firewallConfig:
    internal:
      inboundAllowType: same-gvc
      inboundAllowWorkload:
        - //gvc/amazingapp/workload/users
        - //gvc/bestapp/workload/orders
Available Options:
  • none: No access is allowed between workloads.
  • same-gvc: Workloads running in the same GVC are accessible.
  • same-org: Workloads running in the same org are accessible.
  • workload-list: Specific workloads are allowed access this workload.
    • These workloads can be from the same or different GVCs.
    • The user configuring this setting must have the view permission, set within a policy, on the workload being specified.
    • Use inboundAllowWorkload to list out the allowed workloads using their links.