Amazon EC2
Last updated
Last updated
Let's connect a nodejs app in one AWS VPC with a MongoDB database that resides in another AWS VPC. The example uses docker and docker compose 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?”
This example requires Bash, Git, Curl, and AWS CLI. Please set up these tools for your operating system, then run the following commands:
If everything runs as expected, you'll see the message: The example run was successful 🥳
The run.sh 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.
The run.sh script calls the run function which invokes the enroll command to create a 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 Bank Corp.’s network. The second ticket is meant for the Ockam node that will run in Analysis 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. It passes the enrollment tickets as a function argument to provision Ockam nodes in Bank Corp network and also passes the enrollment key as an function argument to provision Ockam nodes in Analysis Corp.’s network.
For Bank Corp, the run function calls a run.sh script which will create an Amazon VPC that will host our MongoDB instance over a closed network this will be hosted by Bank Corp.
For Analysis Corp, we will also call a run.sh script which will run a nodejs app that will write to our mongoDB data hosted by Bank Corp.
First, the bank_corp/run.sh script creates a network to host the database:
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 with the route table.
We finally create a security group so that there is:
No Outbound connection is allowed for this VPC
Then, the bank_corp/run.sh script creates an EC2 instance where the Ockam outlet 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 the
ENROLLMENT_TICKET is replaced by the enrollment ticket created by the administrator and given as a parameter to run.sh.
Next, the instance is started and the run_ockam.sh script is executed:
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 monitoring-api-inlet="true".
With a relay capable of forwarding the TCP traffic to the TCP outlet.
First, the analysis_corp/run.sh script creates a network to host the nodejs application:
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 with the route table.
We finally create a security group so that there is:
And One SSH ingress to download and install the nodejs application.
Then, we 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 the
ENROLLMENT_TICKET is replaced by the enrollment ticket created by the administrator and given as a parameter to run.sh.
Next, the instance is started and the run_ockam.sh script is executed:
We then create an Ockam node:
With a TCP inlet.
A policy associated to the inlet. The policy authorizes identities with a credential containing the attribute monitoring-api-outlet="true".
Finally, we wait for the instance to be ready and run the nodejs app application:
The app.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:
We connected a nodejs app in one AWS VPC with a MongoDB database in another AWS VPC over an end-to-end encrypted portal.
Non-public access to MongoDB database are only accessible to enrolled members of the project with the appropriate attributes. The communication channel is mutually authenticated and authorized. Keys and credentials are automatically rotated. Access to the API can be easily revoked.
Analysis Corp. does not get unfettered access to Banking Corp.’s network. It only gets access to run queries on the MongoDB server. Bank Corp. does not get unfettered access to Travel App Corp.’s network. It gets access only to respond to requests over a tcp connection. Bank 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. Neither Bank Corp. nor Analysis App Corp. expose any listening endpoints to the Internet. Their networks are completely closed and protected from any attacks from the Internet.
To delete all AWS resources created by this example:
