> ## Documentation Index
> Fetch the complete documentation index at: https://docs.controlplane.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Firewall
> External and internal firewall rules for inbound and outbound traffic. Covers CIDR allowlists, hostname filtering, and HTTP header-based access control.
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 YAML theme={null}
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](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) addresses or allowing all addresses.
* Using the UI:
* Multiple addresses can be 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](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) 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 an IP or CIDR, all ports will be reachable.
* The IP/CIDR addresses takes precedence over hostnames.
* Using the UI:
* Multiple addresses can be 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 YAML theme={null}
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 YAML theme={null}
spec:
firewallConfig:
http:
inboundHeaderFilter:
- key: foo
allowedValues:
- .*
```
Allows all requests except those with the foo=bar header
```yaml YAML theme={null}
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 YAML theme={null}
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](/reference/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](/reference/gvc) to access this workload.
```yaml YAML theme={null}
spec:
firewallConfig:
internal:
inboundAllowType: same-gvc
```
This example allows a few specific workloads across the org to access this workload.
```yaml YAML theme={null}
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 YAML theme={null}
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](/reference/gvc) are accessible.
* `same-org`: Workloads running in the same [org](/reference/org) are accessible.
* `workload-list`: Specific workloads are allowed to 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](/reference/policy#permissions), on the workload being specified.
* Use `inboundAllowWorkload` to list out the allowed workloads using their links.