++ blog / uncloud 2
This commit is contained in:
Nico Schottelius
parent
a45317ab02
commit
7519f26ebb
2 changed files with 120 additions and 18 deletions
|
|
@ -8,7 +8,7 @@ twitter_handle: ungleich
|
|||
---
|
||||
_hidden: no
|
||||
---
|
||||
_discoverable: no
|
||||
_discoverable: yes!
|
||||
---
|
||||
abstract:
|
||||
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.
|
||||
|
||||
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
|
||||
**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
|
||||
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
|
||||
|
||||
So for most of the user created traffic there should not be a firewall
|
||||
rule on the virtualisation stack. Users should be free to configure
|
||||
So for most of the user generated traffic there should be no firewall
|
||||
rules in uncloud. Users should be free to configure
|
||||
their own policies on the VM.
|
||||
|
||||
## 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:
|
||||
|
||||
```
|
||||
chain vm1 {
|
||||
ether saddr != 02:00:f0:a9:c4:4e drop
|
||||
ip6 saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
|
||||
iifname tap1 ether saddr 02:00:f0:a9:c4:4e ip6 saddr 2a0a:e5c1:111:888:0:f0ff:fea9:c44e accept
|
||||
```
|
||||
|
||||
With this we can even allow routing a network to a VM and allowing
|
||||
it to use any IPv6 address in that network:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
## 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
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This way any incorrect mac address and any incorrect IPv6 source
|
||||
address will be blocked. If a customer requested a network for the VM
|
||||
(/64 or /48 for instance), it can easily be prepended to the vm1 specific
|
||||
chain:
|
||||
## Status
|
||||
|
||||
```
|
||||
chain vm1 {
|
||||
ip6 saddr 2a0a:e5c1:111:cafe::/64 accept
|
||||
ether saddr != 02:00:f0:a9:c4:4e drop
|
||||
ip6 saddr != 2a0a:e5c1:111:888:0:f0ff:fea9:c44e drop
|
||||
}
|
||||
```
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -4,3 +4,62 @@
|
|||
- trigger / postgres / etcd
|
||||
- metadata!
|
||||
- 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
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
|
|
|||
Loading…
Reference in a new issue