Security model
The cloud, as its name state, is going to be publically available and is more prone to attacks than the board that lives in a private network.
Principle of Least Privilege
The same principle as described in the board
Limit the area of attack
The architecture of the cloud is the same as the board.
Isolation
On the board, we are using k3s to control the isolation, but in the cloud, we have access to more resources, for the cloud, we are going to use the official Kubernetes implementation.
In the Enterprise Edition each tenant belongs to a particular namespace, that way they are isolated one from another.
The rationale for isolation is the same as the one in the board. View Djinn Board - Isolation
Encryption
When the cloud instance is being created it automatically generates a secret key that belongs to that instance and is used to encrypt all the data that is stored in the local SQLite database.
It also uses secrets as a way to protect sensitive information, the same way they are controlled by the board.
Secure endpoints
All the exposed endpoints are required to use SSL, the gateway and the agent both use gRPC, which supports SSL/TLS for authentication, and the web client which exposes a GraphQL version as well as runs an HTTPS server.
Since in the cloud we have access to more Certificate Authorities we are going to use the certificate from one of these CA instead of one that is self-generated.
explains how can you get a SSL certificate using Let's Encrypt