layout | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Let's connect a nodejs app in one company's Amazon VPC with a CodeRepository hosted on a Gitlab Server in another company's Amazon VPC. The example uses AWS CLI to create these VPCs.
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, AWS CLI, Influx CLI, jq. 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/coderepos/gitlab/amazon_ec2/aws_cli
# Run the example, use Ctrl-C to exit at any point.
./run.sh
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 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 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.
- The run function passes the enrollment tickets as variables of the run scripts provisioning Bank Corp.'s network and Analysis Corp.'s network.
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 two subnets, located in two distinct availability zones, and associated to the route table.
- We finally create a security group so that there is:
- one TCP egress to the Internet,
- one ingress to EC2 running Gitlab from the local machine running the example, to access Gitlab on port 22 and 80.
We are now ready to create an EC2 instance where the Gitlab server and Ockam outlet node will run:
- An SSH keypair to access gitlab repository is created and, the public key is saved in a variable.
- We select an AMI.
- We create an ec2 keypair to access EC2 and to obtain gitlab password to be able to login to gitlab console.
- We start an instance using the AMI above and a start script based on
run_ockam.sh
andrun_gitlab.sh
where:ENROLLMENT_TICKET
is replaced by the enrollment ticket created by the administrator and given as a parameter torun.sh
.SSH_PUBLIC_KEY
is replaced with the Public IP of the EC2 instance inrun_gitlab.sh
script
- We tag the created instance and wait for it to be available.
- We wait for 3 minutes for gitlab to be setup and check it's availability
When the instance is started, the run_gitlab.sh
script is executed:
- Gitlab and it's dependencies are installed.
- Obtain gitlab root password to create access token.
- Password can be used to access the gitlab console from local machine
- Disable public signups.
- Create demo_project.
- Configure access via created SSH Key.
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 gitlab-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 associated 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 application from local machine running the script.
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 torun.sh
.
The instance is started and the run_repoaccess.sh
script is executed:
- The ssh config file is created on the EC2 with details of the private SSH key and permissions are updated
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.
- A policy associated to the inlet. The policy authorizes identities with a credential containing the attribute gitlab-outlet="true".
We finally wait for the instance to be ready and install the nodejs application:
- The app.js file has code to access the code repository on
port 1222
configured in tcp inlet - We can then SSH to the instance and:
Once the nodejs application is started:
- It will connect to the Ockam inlet at port 1222.
- It executes the run function that clones the repository, makes sure README.md file exists, inserts a line to the README.md file, does a commit and push the commit to the remote gitlab server.
We connected a nodejs app in one virtual private network with a Gitlab CodeRepository in another virtual private network over an end-to-end encrypted portal.
Sensitive business data in the Gitlab Codebase is only accessible to Bank Corp. and Analysis 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 InfluxDB can be easily revoked.
Analysis Corp. does not get unfettered access to Bank Corp.’s network. It gets access only to the codebase hosted on the Gitlab server. Bank Corp. does not get unfettered access to Analysis Corp.’s network. It gets access only to respond to queries 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. Bank Corp. or Analysis Corp. don’t expose any listening endpoints on the Internet. Their networks are completely closed and protected from any attacks from the Internet.
To delete all AWS resources:
./run.sh cleanup