++ blog / uncloud 2

This commit is contained in:
Nico Schottelius 2020-01-12 13:28:24 +01:00
parent a45317ab02
commit 7519f26ebb
2 changed files with 120 additions and 18 deletions

View file

@ -8,7 +8,7 @@ twitter_handle: ungleich
--- ---
_hidden: no _hidden: no
--- ---
_discoverable: no _discoverable: yes!
--- ---
abstract: abstract:
Let's secure the VM network Let's secure the VM network
@ -19,7 +19,7 @@ In the second step of building an OpenStack alternative we have a look
on how to secure the network. on how to secure the network.
In the first step we described [how to setup a In the first step we described [how to setup a
protoype](how-to-build-an-openstack-alternative-step-1). protoype](../how-to-build-an-openstack-alternative-step-1).
Note: the name of our OpenStack alternative is Note: the name of our OpenStack alternative is
**uncloud**. **uncloud**.
@ -28,12 +28,12 @@ Note: the name of our OpenStack alternative is
Users should be able to do what they want and not limited in their Users should be able to do what they want and not limited in their
actions. On the other hand, users should be unable to disturb other actions. On the other hand, users should be unable to disturb other
users. users. It's very much like in real life.
## General policy: no firewall ## General policy: no firewall
So for most of the user created traffic there should not be a firewall So for most of the user generated traffic there should be no firewall
rule on the virtualisation stack. Users should be free to configure rules in uncloud. Users should be free to configure
their own policies on the VM. their own policies on the VM.
## Network types ## Network types
@ -92,21 +92,64 @@ IP address of another machine. We can achieve this by adding a chain
specific for each VM network interface: specific for each VM network interface:
``` ```
chain vm1 { iifname tap1 ether saddr 02:00:f0:a9:c4:4e ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44e accept
ether saddr != 02:00:f0:a9:c4:4e drop
ip6 saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
}
``` ```
This way any incorrect mac address and any incorrect IPv6 source With this we can even allow routing a network to a VM and allowing
address will be blocked. If a customer requested a network for the VM it to use any IPv6 address in that network:
(/64 or /48 for instance), it can easily be prepended to the vm1 specific
chain:
``` ```
chain vm1 { iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44f accept
ip6 saddr 2a0a:e5c1:111:cafe::/64 accept iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:1234::/64 accept
ether saddr != 02:00:f0:a9:c4:4e drop
ip6 saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
}
``` ```
## Putting it all together
The following code is a full nftable ruleset
for securing the VM network traffic.
Note that it uses the prerouting hook so
that we can use the **ibrname** statement.
This is necessary because we don't want to
filter after routing or in a forwarding mode, but we want to already filter it
**prerouting** (hence the name).
```
flush ruleset
table bridge filter {
chain prerouting {
type filter hook prerouting priority 0;
policy accept;
ibrname br100 jump br100
}
chain br100 {
# Allow all incoming traffic from outside
iifname vxlan100 accept
# Default blocks: router advertisements, dhcpv6, dhcpv4
icmpv6 type nd-router-advert drop
ip6 version 6 udp sport 547 drop
ip version 4 udp sport 67 drop
jump br100_vmlist
drop
}
chain br100_vmlist {
# VM1
iifname tap1 ether saddr 02:00:f0:a9:c4:4e ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44e accept
# VM2
iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44f accept
iifname v343a-0 ether saddr 02:00:f0:a9:c4:4f ip6 saddr 2a0a:e5c1:111:1234::/64 accept
}
}
```
## Status
With this second step we create the basis for actually running VMs
that we (as an operator) don't trust. So now we have a prototype and
we have network security. We probably want to begin to automate things
in the next step.

View file

@ -4,3 +4,62 @@
- trigger / postgres / etcd - trigger / postgres / etcd
- metadata! - metadata!
- building vm images! - building vm images!
- generate tap names matching vm??? problem, because inteerfaces are
limited in length!
[root@diamond hackcloud]# ip link add b23456789012345 type bridge
[root@diamond hackcloud]# ip link add b234567890123456 type bridge
Error: argument "b234567890123456" is wrong: "dev" not a valid ifname
[root@diamond hackcloud]#
- VMID is not uuid, but counter; using hexa; using 16**10,
gives 1099511627776 VMs
>>> (16**10)/(1000*24*365)
125515.02600182648
interface names:
x = vxlan ?
b = bridge
v = vm
=> 16 types possible
10+1 used => 4 left
2 positions for interface id? => 256 interfaces per VM
mac:
48 bits = 6 bytes
1 byte = 2hexa positions
prefix is 02:00: = 2 bytes
we have 4 bytes = 8 hexa left!!!!
embed mac suffix as ID!
full mac = 12 bytes
No vmprefix + counter -> because counter size might always be wrong
(how many interfaces? 16? 256? ... )
--------------------------------------------------------------------------------
No stale firewall entries as we regnerate, not keep the list!
table bridge filter {
chain prerouting {
type filter hook prerouting priority 0;
policy accept;
ibrname br100 jump netpublic-$version
}
chain netpublic-10 {
...
}
}
can generate new full chain, change only the jump
--------------------------------------------------------------------------------