You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: add resource information, some grammar fixes
Improve the ingress firewall docs.
Signed-off-by: Steve Francis <steve.francis@talos-systems.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
Copy file name to clipboardExpand all lines: website/content/v1.7/talos-guides/network/ingress-firewall.md
+22-13Lines changed: 22 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: "Ingress Firewall"
3
3
description: "Learn to use Talos Linux Ingress Firewall to limit access to the host services."
4
4
---
5
5
6
-
Talos Linux Ingress Firewall is a simple and effective way to limit access to the services running on the host, which includes both Talos standard
6
+
Talos Linux Ingress Firewall is a simple and effective way to limit network access to the services running on the host, which includes both Talos standard
7
7
services (e.g. `apid` and `kubelet`), and any additional workloads that may be running on the host.
8
8
Talos Linux Ingress Firewall doesn't affect the traffic between the Kubernetes pods/services, please use CNI Network Policies for that.
9
9
@@ -29,17 +29,17 @@ ingress:
29
29
except: 172.20.0.1/32
30
30
```
31
31
32
-
The first document configures the default action for the ingress traffic, which can be either `accept` or `block`, with the default being `accept`.
33
-
If the default action is set to `accept`, then all the ingress traffic will be allowed, unless there is a matching rule that blocks it.
34
-
If the default action is set to `block`, then all the ingress traffic will be blocked, unless there is a matching rule that allows it.
32
+
The first document configures the default action for ingress traffic, which can be either `accept` or `block`, with the default being `accept`.
33
+
If the default action is set to `accept`, then all ingress traffic will be allowed, unless there is a matching rule that blocks it.
34
+
If the default action is set to `block`, then all ingress traffic will be blocked, unless there is a matching rule that allows it.
35
35
36
-
With either `accept` or `block`, the traffic is always allowed on the following network interfaces:
36
+
With either `accept` or `block`, traffic is always allowed on the following network interfaces:
37
37
38
38
* `lo`
39
39
* `siderolink`
40
40
* `kubespan`
41
41
42
-
In the `block` mode:
42
+
In `block` mode:
43
43
44
44
* ICMP and ICMPv6 traffic is also allowed with a rate limit of 5 packets per second
45
45
* traffic between Kubernetes pod/service subnets is allowed (for native routing CNIs)
@@ -62,30 +62,33 @@ The `protocol` might be either `tcp` or `udp`.
62
62
The `ingress` specifies the list of subnets that are allowed to access the host services, with the optional `except` field to exclude a set of addresses from the subnet.
63
63
64
64
> Note: incorrect configuration of the ingress firewall might result in the host becoming inaccessible over Talos API.
65
-
> The configuration might be [applied]({{< relref "../configuration/editing-machine-configuration" >}}) in `--mode=try` to make sure it gets reverted in case of a mistake.
65
+
> It is recommended that the configuration be [applied]({{< relref "../configuration/editing-machine-configuration" >}}) in `--mode=try` to ensure it is reverted in case of a mistake.
66
66
67
67
## Recommended Rules
68
68
69
69
The following rules improve the security of the cluster and cover only standard Talos services.
70
70
If there are additional services running with host networking in the cluster, they should be covered by additional rules.
71
71
72
-
In the `block` mode, the ingress firewall will also block encapsulated traffic (e.g. VXLAN) between the nodes, which needs to be explicitly allowed for the Kubernetes
72
+
In `block` mode, the ingress firewall will also block encapsulated traffic (e.g. VXLAN) between the nodes, which needs to be explicitly allowed for the Kubernetes
73
73
networking to function properly.
74
-
Please refer to the CNI documentation for the specifics, some default configurations are listed below:
74
+
Please refer to the documentation of the CNI in use for the specific ports required.
75
+
Some default configurations are listed below:
75
76
76
77
* Flannel, Calico: `vxlan` UDP port 4789
77
78
* Cilium: `vxlan` UDP port 8472
78
79
79
-
In the examples we assume following template variables to describe the cluster:
80
+
In the examples we assume the following template variables to describe the cluster:
80
81
81
82
* `$CLUSTER_SUBNET`, e.g. `172.20.0.0/24` - the subnet which covers all machines in the cluster
82
83
* `$CP1`, `$CP2`, `$CP3` - the IP addresses of the controlplane nodes
83
84
* `$VXLAN_PORT` - the UDP port used by the CNI for encapsulated traffic
84
85
85
86
### Controlplane
86
87
88
+
In this example Ingress policy:
89
+
87
90
* `apid` and Kubernetes API are wide open
88
-
* `kubelet` and `trustd` API is only accessible within the cluster
91
+
* `kubelet` and `trustd` API are only accessible within the cluster
89
92
* `etcd` API is limited to controlplane nodes
90
93
91
94
```yaml
@@ -160,7 +163,7 @@ ingress:
160
163
161
164
### Worker
162
165
163
-
* `kubelet` and `apid` API is only accessible within the cluster
166
+
* `kubelet` and `apid` API are only accessible within the cluster
164
167
165
168
```yaml
166
169
apiVersion: v1alpha1
@@ -200,7 +203,7 @@ ingress:
200
203
201
204
## Learn More
202
205
203
-
Talos Linux Ingress Firewall is using the `nftables` to perform the filtering.
206
+
Talos Linux Ingress Firewall uses `nftables` to perform the filtering.
204
207
205
208
With the default action set to `accept`, the following rules are applied (example):
206
209
@@ -232,3 +235,9 @@ table inet talos {
232
235
}
233
236
}
234
237
```
238
+
239
+
The running `nftable` configuration can be inspected with `talosctl get nftableschain -o yaml`.
240
+
241
+
The Ingress Firewall documents can be extracted from the machine config with the following command:
Copy file name to clipboardExpand all lines: website/content/v1.8/talos-guides/network/ingress-firewall.md
+22-13Lines changed: 22 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: "Ingress Firewall"
3
3
description: "Learn to use Talos Linux Ingress Firewall to limit access to the host services."
4
4
---
5
5
6
-
Talos Linux Ingress Firewall is a simple and effective way to limit access to the services running on the host, which includes both Talos standard
6
+
Talos Linux Ingress Firewall is a simple and effective way to limit network access to the services running on the host, which includes both Talos standard
7
7
services (e.g. `apid` and `kubelet`), and any additional workloads that may be running on the host.
8
8
Talos Linux Ingress Firewall doesn't affect the traffic between the Kubernetes pods/services, please use CNI Network Policies for that.
9
9
@@ -29,17 +29,17 @@ ingress:
29
29
except: 172.20.0.1/32
30
30
```
31
31
32
-
The first document configures the default action for the ingress traffic, which can be either `accept` or `block`, with the default being `accept`.
33
-
If the default action is set to `accept`, then all the ingress traffic will be allowed, unless there is a matching rule that blocks it.
34
-
If the default action is set to `block`, then all the ingress traffic will be blocked, unless there is a matching rule that allows it.
32
+
The first document configures the default action for ingress traffic, which can be either `accept` or `block`, with the default being `accept`.
33
+
If the default action is set to `accept`, then all ingress traffic will be allowed, unless there is a matching rule that blocks it.
34
+
If the default action is set to `block`, then all ingress traffic will be blocked, unless there is a matching rule that allows it.
35
35
36
-
With either `accept` or `block`, the traffic is always allowed on the following network interfaces:
36
+
With either `accept` or `block`, traffic is always allowed on the following network interfaces:
37
37
38
38
* `lo`
39
39
* `siderolink`
40
40
* `kubespan`
41
41
42
-
In the `block` mode:
42
+
In `block` mode:
43
43
44
44
* ICMP and ICMPv6 traffic is also allowed with a rate limit of 5 packets per second
45
45
* traffic between Kubernetes pod/service subnets is allowed (for native routing CNIs)
@@ -62,30 +62,33 @@ The `protocol` might be either `tcp` or `udp`.
62
62
The `ingress` specifies the list of subnets that are allowed to access the host services, with the optional `except` field to exclude a set of addresses from the subnet.
63
63
64
64
> Note: incorrect configuration of the ingress firewall might result in the host becoming inaccessible over Talos API.
65
-
> The configuration might be [applied]({{< relref "../configuration/editing-machine-configuration" >}}) in `--mode=try` to make sure it gets reverted in case of a mistake.
65
+
> It is recommended that the configuration be [applied]({{< relref "../configuration/editing-machine-configuration" >}}) in `--mode=try` to ensure it is reverted in case of a mistake.
66
66
67
67
## Recommended Rules
68
68
69
69
The following rules improve the security of the cluster and cover only standard Talos services.
70
70
If there are additional services running with host networking in the cluster, they should be covered by additional rules.
71
71
72
-
In the `block` mode, the ingress firewall will also block encapsulated traffic (e.g. VXLAN) between the nodes, which needs to be explicitly allowed for the Kubernetes
72
+
In `block` mode, the ingress firewall will also block encapsulated traffic (e.g. VXLAN) between the nodes, which needs to be explicitly allowed for the Kubernetes
73
73
networking to function properly.
74
-
Please refer to the CNI documentation for the specifics, some default configurations are listed below:
74
+
Please refer to the documentation of the CNI in use for the specific ports required.
75
+
Some default configurations are listed below:
75
76
76
77
* Flannel, Calico: `vxlan` UDP port 4789
77
78
* Cilium: `vxlan` UDP port 8472
78
79
79
-
In the examples we assume following template variables to describe the cluster:
80
+
In the examples we assume the following template variables to describe the cluster:
80
81
81
82
* `$CLUSTER_SUBNET`, e.g. `172.20.0.0/24` - the subnet which covers all machines in the cluster
82
83
* `$CP1`, `$CP2`, `$CP3` - the IP addresses of the controlplane nodes
83
84
* `$VXLAN_PORT` - the UDP port used by the CNI for encapsulated traffic
84
85
85
86
### Controlplane
86
87
88
+
In this example Ingress policy:
89
+
87
90
* `apid` and Kubernetes API are wide open
88
-
* `kubelet` and `trustd` API is only accessible within the cluster
91
+
* `kubelet` and `trustd` API are only accessible within the cluster
89
92
* `etcd` API is limited to controlplane nodes
90
93
91
94
```yaml
@@ -160,7 +163,7 @@ ingress:
160
163
161
164
### Worker
162
165
163
-
* `kubelet` and `apid` API is only accessible within the cluster
166
+
* `kubelet` and `apid` API are only accessible within the cluster
164
167
165
168
```yaml
166
169
apiVersion: v1alpha1
@@ -200,7 +203,7 @@ ingress:
200
203
201
204
## Learn More
202
205
203
-
Talos Linux Ingress Firewall is using the `nftables` to perform the filtering.
206
+
Talos Linux Ingress Firewall uses `nftables` to perform the filtering.
204
207
205
208
With the default action set to `accept`, the following rules are applied (example):
206
209
@@ -232,3 +235,9 @@ table inet talos {
232
235
}
233
236
}
234
237
```
238
+
239
+
The running `nftable` configuration can be inspected with `talosctl get nftableschain -o yaml`.
240
+
241
+
The Ingress Firewall documents can be extracted from the machine config with the following command:
0 commit comments