Sponsored by
Sponsored by
We mentioned Actions when talking about the Policy, an Action is a user generated function defined in the Policy Language and called from the application code. Actions publish new Commands and can insert them into the “local database” Graph. Actions can be thought of as providing a contract or API (along with effects) to the application which is implementing the policy. Actions are atomic in nature, only succeeding if all the command policy checks succeed.
action create_user(user_id int, name string) {
publish CreateUser{
user_id: user_id,
name: name,
}
}
Calling an Action
To call an Action, the device will follow the following process:
Figure 3: Calling an Action Workflow
Syncing is how Aranya communicates and reconciles on-graph data with peers. Syncing allows peers to exchange commands and update their graph with newly received commands. The core Sync in Aranya is unidirectional, if a source peer wishes to sync their graph state performing a bidirectional sync, they will need to send their own separate sync request. In its simplest form a peer will initiate a sync request and send a random group of commands to the desired sync source (AC). The source will then compare the snapshot to its own graph, in this case it realizes that A and C as common commands. The source will then respond with a set of commands that the requester is missing (D). More details can be seen in the sync spec.
A slightly more involved example would be Sync with a branched Graph. Again, once Sync is initiated, the requester sends a random selection of commands (noted with the red outlines below) to the source peer. Because there may be new commands within a branch (denoted by the orange circles), we also need to include them in the request command snapshot that is sent. This lets the source peer know what commands the requester has; the source peer will then compare these commands against its own graph. The source will respond back with the commands that the requester is missing (noted with the hashed circles below).
Syncing in Arayna is configurable. A user can utilize the Sync API present in the runtime or the QUIC protocol syncer. The Runtime Sync API consists of the building blocks for syncing in Arayna, if a user wishes to use these APIs, they will need to implement a transport layer themselves. The QUIC syncer module on the other hand is a batteries included implementation for syncing using the QUIC transport protocol.
When peers sync, Commands are sent to the peer and are evaluated by the Policy again on the Peer’s side, against the peer’s local state of the Graph Command history. Synced Command evaluation shares a similar path to the Action Command evaluation, except when a Sync evaluated Command fails it is written to the graph as a recalled Command. For example, if a user is deauthorized on a peer, their commands would be recalled from the graph. Unlike rejected Commands, a recalled Command can still mutate the FactDB .
Figure: Syncing with a Peer Workflow
Commands that fail policy checks after syncing are “recalled”, which executes a different set of policy rules that can manipulate Facts and emit Effects in response. This may happen if a higher priority message is merged before it, changing dependent Facts. For example, if a Fact holds some kind of authorization for access to a resource, an admin may remove that authorization, then a later Command will fail when that fact is missing or changed. The Policy Language allows the schemes for authorization and authority to be designed flexibly, with no set requirements for their operation.
The general workflow for exchanging control plane commands on-graph across two endpoints can be seen below in Figure 2. This workflow assumes a policy has been written and validated for all actions desired in the architecture.
A diagram showing the exchanging of control plane commands on-graph across two endpoints
Figure 2: General On-Graph Workflow
