Amazon EC2

Let's connect a nodejs app in one virtual private network with an application serving a self hosted model in another virtual private network. The example uses the AWS CLI to create these virtual networks.

Each company’s network is private, isolated, and doesn't expose ports. To learn how end-to-end trust is established, please read: “How does Ockam work?”

Run

This example requires Bash, Git, Curl, and the AWS CLI. Please set up these tools for your operating system. In particular you need to login to your AWS account with aws sso login.

Then run the following commands:

# Clone the Ockam repo from Github.
git clone --depth 1 https://github.com/build-trust/ockam && cd ockam

# Navigate to this example’s directory.
cd examples/command/portals/ai/amazon_ec2

# Run the example, use Ctrl-C to exit at any point.
./run.sh

If everything runs as expected, you'll see the answer to the question: "What is Ockham's Razor?".

Walkthrough

The run.sh script script, that you ran above, and its accompanying files are full of comments and meant to be read. The example setup is only a few simple steps, so please take some time to read and explore.

Administrator

• The run.sh script calls the run function which invokes the enroll command to create an new identity, sign into Ockam Orchestrator, set up a new Ockam project, make you the administrator of this project, and get a project membership credential.

• The run function then generates two new enrollment tickets. The tickets are valid for 10 minutes. Each ticket can be redeemed only once and assigns attributes to its redeemer. The first ticket is meant for the Ockam node that will run in AI Corp.’s network. The second ticket is meant for the Ockam node that will run in Health Corp.’s network.

• In a typical production setup an administrator or provisioning pipeline generates enrollment tickets and gives them to nodes that are being provisioned. In our example, the run function is acting on your behalf as the administrator of the Ockam project.

• The run function passes the enrollment tickets as variables of the run scripts provisioning AI Corp.'s network and Health Corp.'s network.

AI Corp

First, the ai_corp/run.sh script creates a network to host the application exposing the LLaMA model API:

• We create a VPC and tag it.

• We create an Internet gateway and attach it to the VPC.

• We create a route table and create a route to the Internet via the gateway.

• We create a subnet, with associate it to the route table.

• We finally create a security group so that there is:

  • One TCP egress to the Internet,

  • And one SSH ingress to install the model and its application.

We are now ready to create an EC2 instance where the Ockam outlet node will run:

• We select an AMI.

• We create a key pair in order to access the EC2 instance via SSH.

• Before creating the EC2 instance we check that the AWS region we are using proposes this kind of instance type. Indeed, we need properly sized instance in order to run a large language model, and those instances are not available in all regions. If the instance is not available in the current region, we return the list of all the regions where that instance type is available.

• We start an instance using the selected AMI and right instance type. Starting the instance executes a start script based on ai_corp/run_ockam.sh where:

  • ENROLLMENT_TICKET is replaced by the enrollment ticket created by the administrator and given as a parameter to ai_corp/run.sh.

• We tag the created instance and wait for it to be available.

When the instance is started, the run_ockam.sh script is executed:

• The ockam executable is installed.

• The enrollment ticket is used to create a default identity and make it a project member.

• We then create an Ockam node:

  • With a TCP outlet.

  • A policy associated to the outlet. The policy authorizes identities with a credential containing the attribute ai-inlet="true".

  • With a relay capable of forwarding the TCP traffic to the TCP outlet.

Health Corp

First, the health_corp/run.sh script creates a network to host the client.js application which will connect to the LLaMA model:

• We create a VPC and tag it.

• We create an Internet gateway and attach it to the VPC.

• We create a route table and create a route to the Internet via the gateway.

• We create a subnet, and associate it to the route table.

• We finally create a security group so that there is:

  • One TCP egress to the Internet,

  • And One SSH ingress to download and install the nodejs client application.

We are now ready to create an EC2 instance where the Ockam inlet node will run:

• We select an AMI.

• We start an instance using the AMI above and a start script based on run_ockam.sh where:

  • ENROLLMENT_TICKET is replaced by the enrollment ticket created by the administrator and given as a parameter to run.sh.

The instance is started and the run_ockam.sh script is executed:

• The ockam executable is installed.

• The enrollment ticket is used to create a default identity and make it a project member.

• We then create an Ockam node:

  • With a TCP inlet.

  • Connected to the ai relay.

  • A policy associated to the inlet. The policy authorizes identities with a credential containing the attribute ai-outlet="true".

We finally wait for the instance to be ready and install the client.js application:

• The client.js file is copied to the instance (this uses the previously created key.pem file to identify).

• We can then SSH to the instance and:

  • Install nodejs.

  • Start the client.js application.

Once the client.js application is started:

• It will connect to the Ockam inlet at port 3000.

• It sends a query and waits for a response from the model.

• The response is then printed on the console.

Recap

We connected a nodejs application in one virtual private network with an application serving a LLaMA model in another virtual private network over an end-to-end encrypted portal.

Sensitive business data coming from the model is only accessible to AI Corp. and Health Corp. All data is encrypted with strong forward secrecy as it moves through the Internet. The communication channel is mutually authenticated and authorized. Keys and credentials are automatically rotated. Access to connect with the model API can be easily revoked.

Health Corp. does not get unfettered access to AI Corp.’s network. It gets access only to run API queries. AI Corp. does not get unfettered access to Health Corp.’s network. It gets access only to respond to queries over a TCP connection. AI Corp. cannot initiate connections.

All access controls are secure-by-default. Only project members, with valid credentials, can connect with each other. NAT’s are traversed using a relay and outgoing tcp connections. AI Corp. or Health Corp. don’t expose any listening endpoints on the Internet. Their networks are completely closed and protected from any attacks from the Internet.

Cleanup

To delete all AWS resources:

./run.sh cleanup