#675 - Node to Node encryption #655
Conversation
OgarOgarovic
force-pushed
the
proposal/675-node-to-node-encryption
branch
from
e14c9dd
to
de7ce2f
Compare
SovereignCloudStack/issues#675 Signed-off-by: Filip Dobrovolny <[email protected]>
Signed-off-by: Ivan Vnučko <[email protected]>
Signed-off-by: Ivan Vnučko <[email protected]>
OgarOgarovic
force-pushed
the
proposal/675-node-to-node-encryption
branch
from
de7ce2f
to
cbd3fdd
Compare
OgarOgarovic
changed the title
There was a problem hiding this comment.
generally LGTM, but I want to reread it a second time, as it's quite a long document, at the very least there are some spelling mistakes lurking in there imho, but I didn't want to comment on minor errors before actually having read the whole thing first.
Will provide more feedback, hopefully tomorrow.
Thanks for working on this!
| | Term | Meaning | | ||
| |---|---| | ||
| | VM | Virtual machine, alternatively instance, is a virtualized compute resource that functions as a self-contained server for a customer | | ||
| | Node | Physical or virtual machine hosting cloud services and compute instances | |
There was a problem hiding this comment.
IMO the definition of Node as a Physical or virtual machine could be confusing when the layer above mentions the VM term as a virtual machine.
Could we just define VM as a virtual machine and Node as a physical one?
| node between different VMs potentially of multiple tenants as this is a | ||
| question of tenant isolation, not of networking security, and encryption here | ||
| would be possibly a redundant measure. Isolation of VMs is handled by OpenStack | ||
| on multiple levels - VLAN/VxLAN/GRE tunneling, routing rules on networking |
There was a problem hiding this comment.
VLAN/VxLAN/GRE
it would be helpful to spell out the full form of the abbreviations OR
add links where the abbreviations are explained OR
add abbreviations to the Terminology table OR
consider using wording like overlay tunnel protocols instead
| ### Potential threats in detail | ||
|
|
||
| We are assuming that: | ||
| * the customer workloads are not executed within SGX or equivalent secure |
| and Virtual IP tunnels. Each node hosting the VIP will open a tunnel for any | ||
| node in the specific network that can properly authenticate. While using | ||
| Ansible, the deployment isn't compatible with kolla-ansible[^ka] and would need | ||
| porting. Also this project retired as of February 2024. |
There was a problem hiding this comment.
Also this project retired as of February 2024.
Comment
I would say that the retirement of the project is important information, that should not start with Also, consider to reword this sentence.
|
|
||
| In our second proof of concept, we decided to implement support for | ||
| openstack-ipsec. The initial step involved creating a new container image | ||
| within the kolla[^kl] project specifically for this purpose. However, we |
There was a problem hiding this comment.
However, we ... something is missing I guess...
| key exchange and encryption/decryption of the traffic it communicates with | ||
| Libreswan[^ls], specifically with its main daemon `pluto`. | ||
|
|
||
| ##### Challanges |
There was a problem hiding this comment.
IMO this is an implementation detail, hence consider removing this section.
Relates: SovereignCloudStack/issues#675