Security model
The board is going to be exposed to the user network and because of this, the board comes with a security model built-in, since security is one of the principles for Djinn we protect the data with Authorization and access control.
On the board, we are going to treat sensitive information as Secrets, k3s supports this concept and is going to encrypt that information and limit the access only to the services that really require them.
Principle of Least Privilege
POLP is going to be the guiding method that is going to be used to build the security of the model, this principle states that we only provide enough access to performed the job that is required.
Limit the area of attack
The board is only going to export two ports, 80 and 443.
Why these ports?
One of the principles is Simplicity, we want to make it easy for the user to use the application without the need to install something and everyone has a device that has a browser, we are going to use HTTPS as the only communication protocol and HTTPS run on port 443.
What about the port 80?
Port 80 is used for HTTP which is insecure, we are going to expose it but not use it, the user could accidentally type port 80 and the board is going to automatically redirect to port 443.
If you are exposing multiple services, how do you expose them in a single port?
For this reason, we are going to handle these services with DNS, the board has an internal DNS server that knows how to handle these requests, so the services would look like this:
| Service | URL |
|---|---|
| Authentication Server | https://oauth.djinn.local |
| Web Client | https://app.djinn.local |
| Gateway | https://api.djinn.local |
Using DNS for naming resolution is not only more secure since we are only exposing a single port, but it also makes the URL easier to read.
Isolation
For the architecture, we are not just following POLP but we are also following the Single Responsibility Principle (SRP), which establishes:
Every module, class, or function in a computer program should have responsibility for a single part of that program's functionality, and it should encapsulate that part.
There are multiple levels of isolation used in the architecture: | Type | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Plugin Isolation | In the board each module is independent of each other, they only know about their own code and the hardware that they have at their disposal | | Process Isolation | On the board each module is independent of the other, they only know about their own code and the hardware that they have at their disposal | | Module Isolation | Every module that exists in the architecture only fulfills a single role (SRP), which limits the control that the module has in the architecture | | Storage Isolation | The filesystem is shared in some sections but at the same time is isolated in others, k3s enable us to enforce filesystem access by the process |
Why do we need isolation?
From a security perspective, if each one of the pieces is isolated from each other and one of them is compromised, this limits the attack to only one module and it doesn't affect the other modules.
Encryption
After the board is installed and rebooting for the first time, it generates a unique encryption key that is stored as a secret in k3s, this encryption key is hidden and is not accessible from the outside world, and is only accessible by the modules that k3s instantiate.
This encryption key is going to be used to encrypt and decrypt all the data that is stored in the database.
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 run an HTTPS server, where the certificate is generated by the board.
How to use HTTPS for local development describes how this can be achieved.
The endpoints that are exposed by the gateway, rely on OAuth authentication, in which the board provides an OAuth Resource and Authentication built-in.