VeilNet access control is different from regular network policies. You do not create rules based on subnet or IP address. Instead, you will create teams.
What is a Team in VeilNet? #
VeilNet Team is an identity that you can associate with Plane, Users and VeilNet Conflux instances. It is a similar concept to “Taint” for a node in a Kubernetes cluster, which defines affinities.
In VeilNet, each Team will have its own cryptographic hash signature that will be used by VeilNet Conflux, along with Dilithium Digital Signature for authentication in a decentralised manner.
This means, unlike other overlay network providers whose access control relies on the connection between the connector and centralised coordination server(s), VeilNet Conflux will maintain access control even if VeilNet Guardian Server is offline.
How does it work? #
Only VeilNet can adopt such identity-based access control because VeilNet Conflux is capable of packet-level user authentication. This is impossible for other overlay networks that are based on an IP network and WireGuard.
After VeilNet Conflux is authenticated by the VeilNet Guardian server and joins VeilNet, it will pull down its associated “Teams” (identities) granted by the owner (User). Whenever a packet is sent, a cryptographic hash will be created from each identity based on the VeilNet Conflux instance’s Dilithium public key. Whenever a packet is received, the VeilNet Conflux will calculate the cryptographic hash of its own identities based on the sender’s Dilithium public key and confirm any affinity, meaning at least one hash is the same. Therefore, the identities are never shared on the network, globally verifiable but also unique to each VeilNet Conflux instance. During the unlikely event that all VeilNet Guardian servers are offline, VeilNet Conflux instances will maintain their identities from their last update to maintain access control.
It is impossible for a VeilNet Conflux instance to impersonate others because:
- Impersonating Dilithium Public Key is impossible: Dilithium DSA is a post-quantum digital signature standards that produce a digital signature via a private key, which could be later verified by a public key. VeilNet Conflux instance produces a Dilithium DSA signature for every packet with its own random instance signature as context. The pair of Dilithium public key and instance signature is immutable and is announced when an instance joins the network. Impersonating Dilithium Public Key will break the immutable pair that can be directly detected by other instances and lead to a verification error.
- Impersonating Identity Hashes is impossible: If a VeilNet Conflux instance attempts to impersonate another instance by copying the public key, random instance signature and all identity hashes, it can not produce a valid packet Dilithium DSA due to missing private key. The private key is only stored in each instance’s memory and never shared across the network.
Imagine each VeilNet packet is sealed with wax and stamped uniquely, and the stamp only exists in the owner’s mind, and every will reject packets if its seal is broken or has changed. The security offered by VeilNet is beyond the definition of a Zero-Trust network as it only regulates access to resources, not the packets themselves.
Create a Team #
To create a team, select the fourth navigation title “Organisation & Team” inside the right panel of the main page. Then, you will see the page below:
If you do not have an organisation, you will see the creation form shown above. You do not have to own any actual organisation. The organisation is used to organise your teams only, and you could input any name, email or website (we will expand features in the future).
After an organisation is created, you will see a new expansion title on the right. Click to expand it, then you will be able to create a new team by entering a name and an email address. The “Owner” team is created for you, and anyone inside this team is considered an owner of the organisation. The owner of an organisation will be able to create and delete teams belonging to it. The “Owner” team could not be deleted.
Invite Team Member #
To invite a user to join the team as a member, simply input their VeilNet account email and click the “invite” button. Any pending invitation will show up on the left side. To cancel the invitation, simply click the “cancel”. The Team invitation will be presented to the target user on the main navigation page, and same location on the “Organisation & Team” page. The target user can accept or reject the invitation.
Associate Plane to Team #
Both Community Plane and Private Plane can be associated with a team. If a Private Plane is associated, the team members will be able to deploy a VeilNet Conflux instance under the associated Private Plane, effectively achieving “sharing network” in other overlay network providers. However, we do not limit the number of teams or the number of members per team.
A Plane can be associated with multiple teams. Please keep in mind that the VeilNet Conflux instance does not automatically inherit the teams associated with the Plane it belongs to. You must also associate the team with Conflux instances under the Conflux management page.
Associate Team to Conflux #
There are two ways to associate Team identity with a Conflux instance:
- Via CLI during registration: The Team identity could be given to a Conflux instance by the user “–teams” flag, followed by a comma-separated list of teams. The Conflux instance will acquire those identities if the user is a member or owner of the team. Otherwise, the team will be ignored.
- Associated via UI: Head to the Conflux management page on our Auth Portal. Expand the Conflux card under any Plane. If the Conflux instance is operating in Portal Mode, a group of chips representing each team will be shown. Simply click on the chips to add or remove a team identity from the instance. You do not have to reboot the instance; this change will be effective immediately.
How does access control by Team work #
VeilNet access control is based on affinity. For a pair of Conflux instances communicating with each other, they must share at least one affinity. Let’s explain through an example.
Assume we have two Confluxes belonging to James and Ben. By default, following the Zero-Trust principle, their Conflux instances will only have the user identity. Therefore, if James wants to access Ben’s local network 192.168.0.0/24, Ben’s Conflux instance will “play dead” (dropping all control and data messages silently) because they do not share any common identities. Therefore, James will not be able to access the local network, and in fact has no knowledge about the local network.
To allow James access to the local network 192.168.0.0/24, Ben must create a Team and invite James as a member. Then, associate the Team with the Conflux instance. Now, if James connects to VeilNet via a Conflux that operates in Rift mode, he will be able to access the local network that belongs to Ben. If James associates the Team with his Conflux operating in Portal mode, then Ben will be able to access the local network on James’s side.
A VeilNet Conflux instance can be associated with multiple teams to enable more complex access control. For example, a staging server with Conflux instances associated with both “Dev” and “Stage” teams to allow access from two groups of employees. A development server with Conflux instances associated with the ‘Dev’ team only to block access from employees responsible for staging. Then, maybe a production server with Conflux instances associated with the “Prod” team, so none will accidentally access it except the employees responsible for production. The idea is simple: you should implement your access control based on your business logic, rather than IP address or subnet.
How do I block a certain host network for a team? #
At the moment, VeilNet Conflux does not have the ability to block certain host networks for a team. This feature will be added in our next update.