Welcome to Araali Networks’ Community Edition!

Araali Networks Community Edition is dedicated to the hardworking community of DevOps so as to imbibe a culture of continuous monitoring and security to be an essential part of the job function. DevOps is about busting silos, and we are here to bust some more.

We seek to make it easy and fun. We uplift the grammar of network security to make it meaningful for the DevOps audience.

This has a transformative effect on security because an air-gapped environment is quite secure. What brings insecurity ought to fix it too. And that we do with zero trust - simplified to its essence, and democratized. It’s rare for something to be simple, and yet uplift the security posture all at once. And on top of it make a promise of no harm.

Through our assessments, we hope you will find answers to the following questions:

• Where are my crown jewels?

• Who is accessing them?

• Are services accidentally overexposed to the public Internet?

So let the show begin!

Introduction to Araali Networks

What is Araali?

Araali transparently secures the network connections between services deployed on VMs, containers, and container management platforms like Kubernetes. It creates an identity-based, passwordless system that performs authentication, authorization, and audit for any inter-service communication out of the box. The identity-based paradigm is critical for modern cloud-native constructs where infrastructure is ephemeral, and security tools cannot use network-based constructs like IPs and ports.

At its core, Araali leverages eBPF, the superpower of Linux and an identity paradigm inspired by SPIFFE/SPIRE. It provides powerful visibility and security controls without any code recompiles/changes, has no performance penalty, and guarantees no disruptions by staying out of the packet forwarding path. Araali deploys with a single command to cover your fleet of nodes on the Kubernetes cluster(s) or VMs across clouds.

Visibility

Once deployed, you instantly see your apps and services as an easily-understood network diagram and can use this to discover anomalies. Araali covers inter-cluster, intra-cluster, ingress, and egress traffic based on DNS in use (if any).

It also works beautifully for hybrid environments where your Kubernetes cluster might be communicating with databases on VMs or workloads spanning multiple clouds and on-prem.

Security

Araali auto-discovers identity-centric policies that are then reviewed and accepted via APIs or the Araali UI. Once these are accepted, you can turn on alerts that carry the appropriate context and are intelligently dispatched to the right app owner. Until this point, Araali is running in the no-harm monitoring and alert mode.

Once you have monitored your apps for a period, you can turn on enforcement with the flip of a switch, and Araali can enforce all the policies. Enforcement means that only the whitelisted/accepted policies will be allowed, and everything else will be dropped. Enforcement is an intrusive mode, and we recommend you actively monitor for no alerts for a few days.

We recommend starting your journey inside out, focusing on your crown jewels first. Once enforced, it will give you peace of mind that only legitimate processes can talk to the data layer, and nothing else. You should then slowly expand in concentric circles and build depth into your defense.

Key Insights in Building Araali

As the cloud gained prominence, networking was abstracted from the operations teams, as they did not own or control the networking boxes anymore, and focus shifted to IAM roles. Furthermore, the networking controls that the cloud providers offered (Security Groups) were primarily IP and port-based and predated the network security stack by over a decade.

Araali’s critical insight was to decouple security from the infrastructure and create it as an overlay that could be implemented in a distributed fashion. Every node/VM gets its personal eBPF based firewall which could enforce Zero Trust security based on Identities. The identity-based policy is auto-discovered to free Dev and SecOps team from having to handwrite declarative policies.

eBPF has enabled visibility and control over apps and services at a granularity and efficiency that was not previously possible without any recompile or rewrite. Also, it is well-equipped to handle modern containerized workloads as well as more traditional workloads such as virtual machines and standard Linux processes, as long as these are running modern Linux kernels that support eBPF.

Araali Support Matrix

Araali supports both VMs and Kubernetes running on Linux. The free assessment is currently available for Kubernetes only.

Araali leverages eBPF technology which is generally available in kernel 4.10 onwards. Watch this talk to learn more about eBPF.

Below is the list of versions we have actively tested out, but we believe we would cover more than what’s listed here. If you are having any issues, contact us via the slack channel.

.

Term and Conditions

GENERAL

The Araali Freemium product covers up to 5 apps for up to one hour for a point-in-time assessment. To cover more apps, the user can evaluate a paid version of the product on AWS Marketplace.

EVALUATION

The parties agree and acknowledge that the evaluation of the Service conducted by the Evaluator is intended to understand the posture of their environment and take the right actions to fix it. Araali is not responsible for protecting the Evaluator’s environment.

RESTRICTIONS

The evaluator must not modify, disassemble, decompile, reverse engineer, rent, lease, loan, transfer, or copy any portion of the Software. The evaluator must not circumvent or disable any security or other technological features of the Service.

OWNERSHIP

Araali owns all rights, title, and interests, including all intellectual property rights, in and to the Service, including any improvements, modifications, and enhancements to it. Except as expressly provided in this Agreement, no party transfers, assigns, or otherwise conveys to the other party any right, title, or interest in such first party’s intellectual property rights.

FEEDBACK

The evaluator has no obligation to provide Araali any suggestions, comments or other feedback regarding the Service (“Feedback”). If Evaluator nonetheless provides Feedback to Araali on any version or part of the Service, Evaluator hereby grants to Araali the right to freely use, disclose, reproduce, license, distribute and otherwise commercialize the Feedback in any Araali product, technology, service, specification, or other documentation.

WARRANTY DISCLAIMER

The service is provided “AS IS” for testing only, and Araali does not warrant that the service will operate without error or interruption. Araali specifically disclaims all other warranties, express or implied, including the implied warranties of merchantability, non-infringement, title, quality, accuracy, and fitness for a particular purpose.

Installation

In this guide, we’ll walk you through how to install Araali software into your Kubernetes cluster or Linux VMs and secure your cloud native runtime. We have made it easy for you to single-click install as well as uninstall Araali.

Overview: Installing Araali is simple. The first step is to self-serve onboard by creating an account on Araali UI. After that, for K8s, helm install Araali software onto your Kubernetes cluster, run the Software you want to secure, and come back to the Araali UI for insights.

Steps for securing workloads running on Linux VMs are similar and described below.

NOTE: You should have outbound port 443 open for Araali to talk to its SaaS backend (normally it is already open).

Step 1: Sign In or Create a new Login using the Araali UI

NOTE: Your Araali account is automatically created on first login. If you want to be part of another person’s (or, team’s shared) account, ask them to add you as a user in their account before attempting to login.

Visit the Araali Console in your browser. If you have a Gmail or GSuite powered email, click the “Sign in with Google” button to access the Araali UI with single sign on (SSO). There is no need to create a seperate Araali login.

If you do not have a Google powered email, use the “Sign up” button to create an Okta powered account using a non-google email.

Step 2: Generate values.yaml for Installation

Go to Araali UI and select Administration -> “Cluster Fortification” in the left-hand panel.

Click on “+” and provide a name for your workload template. The generated values.yaml can be used for both VMs and K8s clusters:

• To fortify multiple clusters the “zone” in the downloaded values.yaml must be changed per cluster (to represent the name of the cluster). For e.g. Kustomize can be used to automate multi-cluster deployments.

• To fortify VMs both zone and app must be changed prior to fortifying individual VMs.

Now download the file (example below) and save it as values.yaml file

araali:
    workload_id: <wrk-id-variable>
    zone: <zone>

Step 3A: Installation for Kubernetes

Add Araali Repo and Install the Helm Chart.

1. Add Repo*:

   helm repo add araali-helm https://araalinetworks.github.io/araali-helm/
   
   #If you have already added the repo, instead run this command periodically to keep you repo up to date:
   
   helm repo update
   

2. Check if you are fortifying the right cluster by looking at the current context, the name with a “*” is the one you are pointing to right now:

   kubectl config get-contexts
   

3. Install by using the generated values.yaml file:

   helm install -f ./values.yaml my-araali-agent araali-helm/araali-agent
   

   Uninstall:

   helm uninstall my-araali-agent
   # The above only uninstalls the installer(due to a bug). Use the command below to uninstall all araali components
   kubectl delete daemonset,namespace,serviceaccount,clusterrole,clusterrolebinding,deployment,service,secret,configmap,crd -l is_agent=true -A
   kubectl delete daemonset,namespace,serviceaccount,clusterrole,clusterrolebinding,deployment,service,secret,configmap,crd -l is_araali=true -A
   

Step 3B: Installation for VMs

NOTE: If you have already fortified your Kubernetes cluster, you do not need to additionally fortify your VMs. These instructions are only for the non-Kubernetes case.

Cloud providers like AWS provide a hook to install software at the time of VM launch. The generated values.yaml can be used in these init scripts to perform the VM install at boot. The same approach also works on a live running VM (even without the init hook). It can also be used to embed into terraform.

We need to change the zone and app in values.yaml based on where (e.g. the zone could be changed to prod, staging, qa, or dev) and what app (e.g. redis, mongoDB, cassandra) will be running on the VM.

Example: Install via AWS EC2 Instance UserData The following represents a way to embed araali software into an ec2 instance via UserData at bootup time. Both values.yaml, and araalictl should be accessible to the ec2 instance. Embed this script into UserData:

#!/bin/bash
# Note: before every command using wget on a file, run the following command: rm -f <filename>
# Otherwise wget will name the file as .1, and you will be working off a stale copy
wget -q https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.linux-amd64
wget -q https://<resourceAccessUrl>/values.yaml # depending on where customer keeps this file
chmod u+x araalictl.linux-amd64
./araalictl.linux-amd64 editvalues -zone=<zone> -app=<app> -f values.yaml
sudo ./araalictl.linux-amd64 fortify-local -f values.yaml

On success, araalifw agent should be running on the VM, and providing functionality. Any failure conditions are in general recorded in /var/log/cloud-init-output.log.

Uninstall:

sudo ./araalictl.linux-amd64 unfortify-self

Review the Results

Araali UI

Go to the Araali Console and log in with the same email that was used to authorize araalictl.

The Insights section on the Dashboard pull out nuggets of high priority information for you, such as:

• Database, DB-as-a-Service - your crown jewels

• World Exposed Process - check for accidental exposures

• Privilege Access Process and Containers - these have over privileges and can cause significant damage if exploited

• Critical Vulnerability Containers - these are running with critical CVEs

• SaaS Services - All the SaaS services consumed by your apps

• Log4j - to identify if you have any log4j vulnerability in your environment

You can click on any of the cards to review the details.

YAML File

Access the assessment report using the following command

./araalictl assessment -report

Appendix

If you are unable to use Helm for K8s fortification follow the below instructions

Requirements: You should have access to a modern Kubernetes cluster and a functioning kubectl on your local machine. If you don’t already have a Kubernetes cluster (e.g. EKS, GKE, AKS, RancherD), one easy option is to run one on your local machine. There are many ways to do this, including Canonical’s production-ready microk8s for Ubuntu .

You can validate you have a working setup by running

kubectl version --short

You should see the output with both a Client Version and a Server Version component.

Fortify your cluster using Araalictl

1. Check current context, the name with a “*” is the one you are pointing to right now:

   kubectl config get-contexts
   

2. Fortify your cluster

   • If araalictl and kubectl are running on the same machine:

     ./araalictl fortify-k8s -auto -tags=zone=<optional-zone-override> -context=<context of k8s cluster>
     

   • If araalictl and kubectl are not running on the same machine:

     # Create yaml file to fortify your cluster
     ./araalictl fortify-k8s -tags=zone=<optional-zone-override> -context=<context of k8s cluster>
     
     # The above command will generate araali_k8s.yaml file. Copy it to the k8s control plane (where kubectl is running) and then apply
     kubectl apply -f araali_k8s.yaml
     

3. Check if Araali is installed

   • Araali should be running in two namespaces (1) araali-operator and (2) kube-system:

     kubectl get pods -A
     

   

Uninstall Araali

If araalictl and kubectl are running on the same machine:

./araalictl fortify-k8s -delete -context=<context of k8s cluster>

If araalictl and kubectl are not running on the same machine:

kubectl delete -f araali_k8s.yaml

VM Installation using Araalictl directly

Araalictl is a command line tool that can also be used to fortify VMs.In the steps below we will first show how to download and authorize araalictl and then fortify a VM with it.

Step 1: Download Araalictl

If this is your first time running Araali, you will need to download the “command-line tool” araalictl onto your local machine. You can either download it from the Araali UI or curl it in.

To download araalictl from the Araali UI

Navigate to Download, under Support on the left-hand panel, and download the araalictl for your Linux or Mac machine.

To curl araalictl directly to your VM, run:

# On Linux
curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.linux-amd64

# On Mac
curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.darwin-amd64

Step 2: Authorize your Araalictl

First, make your araalictl executable:

chmod +x araali*

ln -sf araali* araalictl

Authorize your session

sudo ./araalictl authorize <CORRECT EMAIL ADDRESS>

NOTE: To correctly authorize araalictl, please enter the same email that was used to sign into the Araali Console.

Now, go to Araali UI and Navigate to Araali Tools, under Administration on the left-hand panel.

Click on the “refresh” button if you don’t see “Approve” and click to approve araalictl. Also, the session-id listed on your araalictl will match the session-id shown in the UI.

The “Approve” button should go away and you will see the “Revoke” button which could be used to revoke the araalictl

Step 3: Fortify your VM

Requirements

1. You should have a Virtual Machine already set up in order to fortify it with Araali.

   • Alternatively, if you have a cluster of VMs and wish to fortify them all through a CM VM, see the Remote Fortification section.

2. You should have port 443 egress open on all VMs for Araali to talk to its SaaS backend.

Self Fortification

1. Generate local ssh-keys (optional and only if you don’t already have id_rsa.pub in your ~/.ssh directory)

ssh-keygen

2. Copy the public key to authorized_keys to allow passwordless local ssh access

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

3. If you don’t have passwordless sudo setup, edit the sudoers file as shown

sudo visudo

4. Allow for password-less sudoers

# Scroll to the very bottom of the file, add the following line
# Replace <user> with the user for the VM
<user> ALL=(ALL) NOPASSWD: ALL

# ^X to save and exit editor

5. Self-Fortify

./araalictl fortify-live  -fortify -tags=zone=<zone_name>,app=<app_name> localhost

Remote Fortification

1. Check Control VM

   • A Control VM (CM VM) that has ssh access to the other VMs is used to remotely fortify from one place.

     

   • It is important that araalictl is downloaded and authorized on the Control VM so that it can remotely install Araali on the rest of the VMs.

   • Remotely Fortify

   ./araalictl fortify-live -fortify -tags=zone=<zone_name>,app=<app_name> <remote_user>@<remote_host>
   

To update Zone and/or App tags of an already fortified VM

./araalictl fortify-live -add -tags=zone=<updated_zone>,app=<updated_app> <remote_user>@<remote_host>

We recommend using your Configuration Management VM (Ansible, Salt, Puppet, Chef, etc.) as the control VM.

Uninstall Araali

Self:

./araalictl fortify-live -unfortify localhost

Remote:

./araalictl fortify-live -unfortify <remote_user>@<remote_host>

Understanding Araali Assessment

In this section, we’ll walk you through the key security insights uncovered by Araali assessment. Much of the information can also be obtained as a yaml report, but the CVE annotation is available only on Araali UI.

1. Overall count of services in your environment categorized as - publicly accessible, internal only, and in use external services

2. Important services / datastores (DBs and DBaaS) that you might want to protect with zero-trust

3. Test for important services being accessible by intruders?

4. Inactive listen ports found in the environment

5. Report of vulnerable VMs and Containers (UI only)

How can you use this information:

First and foremost, it produces a comprehensive, layered diagram of your environment and shows all the active apps and services.

This information helps you understand if you have any security misconfiguration in your environment; for example, your DB might be accidentally exposed to the world or accessible by intruders within your environment (lack of access controls).

Similarly, intruders might have access to your credential stores and in particular the metadata service, which holds keys to access cloud resources (CapitalOne Breach, 2019).

Also, it allows you to monitor your software supply chain - we call it monitoring your monitors.

Finally, you can visualize the flow of data between applications in your environment, annotated by any unpatched vulnerabilities, to help identify risk and prioritize potential remediation efforts.

Yaml output

You can generate the sample report using:

./araalictl assessment -report

The report has many sections that are laid out in the diagrams below.

The top part of the report is the summary for the cluster.

1. Number of zones (or kubernetes clusters) = 1

2. Number of apps (or kubernetes namespaces) = 6

3. Number of internal services (not publicly visible) = 24

4. Number of external services consumed = 27

5. Number of services provided (publicly exposed) = 29

Database in your stack are listed under “databases” or “dbaas,” if you are running the database as a service. Depending on the database or dbaas you can see the name of the process or port and also if the database is accessible from an outside pod. If your db has unnecessary exposure, you will see the flag is_accessible as true.

Top consumed services are a list of external services/egress going out of your environment.

Inactive port services are services that have open ports that are not being used during the assessment. We encourage you to verify and close these ports if not in use.

Internet exposed services are your services that are world visible or exposed on the internet. Any misconfiguration that leads to internet exposure will show up here.

Geo org accessors are services that access external/3rd party services organized by organization name and country.

Starred Lens is a list of important services and apps - your apps running Databases or services that have a high number of connections. They are auto-discovered and starred and will also show up on your Dashboard page.

Navigating via the UI

You can log into the UI to get visual information on your cluster, created out of the box by Araali. You start with a dashboard which is similar to the yaml file summary and gives you a high-level count of services and compute and auto-starred apps, pinned on the top part of the UI.

You can drill into your cluster by clicking on Runtime or Zones. On the zones page, you will get a high-level view of your cluster. The left hand is the ingress and the right hand is the egress made from your cluster. If you have internet exposure, you will see a world map on the left-hand column. Similarly, if you have a sneaky command and control, it will show up on the right-hand side.

You can further drill into your cluster to get to the namespace view by clicking on the magnifying glass in the cluster’s card.

You can see all the namespaces listed out here with both ingress and egress connections clearly listed out.

You can further drill inside any namespace by clicking on the magnifying glass. We will go to the strutfrontend namespace. Inside the namespace, you can see all the processes running as part of that namespace. If you have a database it will show up in the middle row as a card, if you have a dbaas it will show up in the egress column. In the example here we have a process with just ingress and no egress. The process also has inactive ports matching what we saw in the yaml file.

We encourage you to go through all the namespaces and verify your apps, especially if it has a database or if it is using a database as a service.

Command Line Doc

token

./araalictl token

Generate token for api use (programmatic access)

authorize

sudo ./araalictl authorize

Used to authorize this copy of araalictl.

Without any arguments, it will initiate the authorization and also auto-upgrade to the latest published production version.

-check

check authorization status

-clean

clean up and logout

-token <fname>

Use fname for token based auth. If - is used for fname, token is expected to be piped through stdin

Usage:

# generate a token for api use
TOKEN=$(./araalictl token)

# usually TOKEN is generated elsewhere and injected with env vars
echo $TOKEN | sudo ./araalictl authorize -token=-

assessment

./araalictl assessment

Used to start and stop point in time assessments

-start

start the assessment

-stop

stop the assessment

-report

get a report on findings

-ignoreMK8S

ignore MicroK8S even if present

version

./araalictl version

Used to get the version of araalictl

-v

verbose

upgrade

sudo ./araalictl upgrade

Upgrade araalictl to the latest version available.

Python API Doc

Setup

api.set_araalictl_path(new_path)

set the location of araalictl on this node.

Parameters:

new_path (string) – araalictl path

api.auth(token)

authorize araalictl for api use. This operation is idempotent and can be run multiple times without any side effect App.

Parameters:

token (string) – token is generated from a manually authenticated araalictl

api.deauth()

deauth araalictl from this node.

App

class api.App

A class representing an application

Usage:

>>> import api
>>> app = api.App("nightly", "bendvm")
>>> for link in app.iterlinks():
...    link.accept()
...
>>> app.review()
>>> app.commit()

Parameters:

• zone (string) – name of the zone

• app (string) – name of the app

iterlinks()

An iterator for all links of the app

Return type:

iterator of api.Link

review()

Review edits made to links in the app. Links can be accepted, denied or snoozed.

commit()

Commit changes made to links in the app.

Link

class api.Link

Class representing an individual link (policy suggestion). Links can be accepted or snoozed. Accepted links become whitelist policies for the app, while snoozed links will appear again if new flows are observed.

Usage:

>>> for link in app.iterlinks():
...    link.accept()
...

accept()

Accept link as whitelisted policy.

snooze()

Snooze link. A snoozed link is forgotten. It will show up again if a new flow is observed. Typically links are snoozed when the underlying problem is addressed. It is snoozed so that there is notification on subsequent occurrence.

deny()

Deny link. A denied link is snoozed forever. You not only want to not accept it, but you dont even want to snooze because you are aware of it and dont want to accept it, ever!

LinkTable

class api.LinkTable

Class representing an arbitrary table/collection of links (policies), that allows action on multiple links at the same time. Links can be filtered at init, so only filtered links enter the table.

Subsequently action can be taken on all links in the filtered table, or by specifying specific indices. Links can be committed back on a per app basis or for the entire runtime (which essentially iterates over every app in the runtime).

Usage:

>>> links = api.LinkTable(app.iterlinks())
>>> links = links.accept(0,2)
>>> app.review()
>>> app.commit()

Parameters:

• links (list of api.Link) – a list of link objects

• *filters (lambda returning boolean) – filter to be applied on the input (of links). An arbitrary number of filters can be specified. There are some predefined filters in the api for common use: api.f.*

accept(*args)

Accept link by index number. If no index is provided, all links in the table will be accepted.

Parameters:

args (any number of int's) – Multiple indices can be passed

deny(*args)

Deny link by index number. If no index is provided, all links in the table will be denied.

Parameters:

args (any number of int's) – Multiple indices can be passed

snooze(*args)

Snooze link by index number. If no index is provided, all links in the table will be snoozed.

Parameters:

args (any number of int's) – Multiple indices can be passed

Golang API Doc

Setup

araalictl.SetAraalictlPath(newPath)

set the location of araalictl on this node.

Parameters:

newPath (string) – araalictl path

araalictl.Authorize(token)

authorize araalictl for api use. This operation is idempotent and can be run multiple times without any side effect App.

Parameters:

token (string) – token is generated from a manually authenticated araalictl

araalictl.DeAuthorize()

deauth araalictl from this node.

App

class araalictl.App

A struct representing an application

Usage:

app := araalictl.App{ZoneName: "nightly", AppName: "bendvm"}
app.Refresh()
app.Links[0].Accept()
app.Commit()

Parameters:

• ZoneName (string) – name of the zone

• AppName (string) – name of the app

Refresh()

Fetches all the links for the app and links are accessible as app.Links.

Commit()

Commit changes made to links in the app.

Link

class araalictl.Link

Struct representing an individual link (policy suggestion). Links can be accepted, denied or snoozed. Accepted links become whitelist policies for the app, denied links help with ignoring alerts until taken care of while snoozed links will appear again if new flows are observed.

Usage:

app.Links[0].Accept()

// or,
app.Links[0].Snooze()

// or,
app.Links[0].Deny()

Accept()

Accept link as whitelisted policy.

Snooze()

Snooze link. A snoozed link is forgotten. It will show up again if a new flow is observed. Typically links are snoozed when the underlying problem is addressed. It is snoozed so that there is notification on subsequent occurrence.

Deny()

Deny link. A denied link is snoozed forever. You not only want to not accept it, but you dont even want to snooze because you are aware of it and dont want to accept it, ever!

Notebook Doc

Araali creates per app diagrams out of the box. These are not just diagrams, they actually represent policies that have been automatically figured out for you. All that is needed of you is review. Once reviewed, the diagrams are natively enforced by our purpose built firewall.

The policy is represented as a link DB, and you can do data science on these links. This is quite useful as you tinker around with what Araali has discovered. The same APIs can be run outside of the notebook as a regular program/script.

Getting started

In a terminal:

# Create a directory where you will checkout from github
mkdir -p opensrc
cd opensrc
git clone https://github.com/araalinetworks/api.git

# now run the notebook
cd api/python/
./run.sh

Accessing Notebook

To access the notebook, copy and paste this URL into your browser:

• App Lens Notebook

• Admin Notebook

NOTE: Locate token to use in the terminal output

Plain old scripting

If you are not familiar with notebook, you can also write old style scripts:

$ source araali/bin/activate && python3 myscript.py
$ cat myscript.py

  import api
  import araalictl
  print(api.Lens.monitor_world())

Documentation

Use the python tab in this guide:

https://araali-networks-api.readthedocs.io/en/latest/guide_lenses.html

Understanding Araali Policies

Araali Policies

Discover

One of the most beneficial features of Araali is its policy paradigm. It automatically discovers policies for every namespace/app - no need to write declarative policies. Besides, Araali uses identity instead of IP and Port for policies. The identity paradigm is more relevant in the modern cloud-native environment where IPs are ephemeral. Araali’s identity is inspired by SPIFFE/SPIRE.

When you run Araali assessment, it discovers the communication between services identities and automatically suggests those policies as a diagram. In the diagram, each box represents a process. It will have an identity if Araali is running or a DNS or IP address if there is no Araali. The lines between these boxes represent network communication - all the links will start their lifecycle as alerts as shown in the above diagram.

Review

Araali provides various ways of reviewing the links once we are done with the discovery step. We can verify the communication pattern of an application through our UI or our API. Links that were discovered can be transitioned to one of the following states.

1. Allowed

Links accepted as whitelist policy.

2. Snoozed

A snoozed link is forgotten. It will show up again if a new flow is observed. Typically links are snoozed when the underlying problem is addressed. It is snoozed so that there is a notification on subsequent occurrences.

We will be able to snooze erroneous whitelisted/denied policies as well.

3. Denied

A denied link is snoozed forever. You neither want to accept nor snooze because you are aware of it and don’t want to be bothered by it again.

Enforce

Once policies are reviewed, they are ready to be enforced. Creating guard rails and monitoring for deviations vs enforcing them upfront is a business decision that depends on the value of the resource being protected. Araali allows you to make these decisions at a very fine granularity - at a per app and per service level

Managing Policies in Araali UI

We drill down to the app page from the zone page selecting the zone we are interested in and from there we choose the app we are interested in and land on our policy page for that app.

1. Accepting

1. Choose the red line for each connection that you want to approve.

2. Choose the check mark. The line turns green.

Validate and accept all approved connections. This converts them to policies.

That’s it—you have created allow-list policies for your app! No need to manually discover and write declarative policies.

2. Snoozing

1. Choose the red line for each connection that you want to snooze.

2. Choose the timer icon. The line turns blue and is hidden by default.

3. Denying

1. Choose the red line connection you’d like to snooze forever.

2. Choose the bell icon. The line turns yellow.

The snapshot below shows some of the transitions made on our UI.

Managing Policies Araali API

The above data can be accessed as python objects as well using our API. We can set up python API as described here.

Fetching links for a given zone and app.

import API
app = api.App("azuref", "wordpress")

# We can access the links part of the app as below.
for link in app.iterlinks():
  link.to_data()

Once we have the links we can take the following actions.

1. Accept an alert as defined policy.

app.links[0].accept()

2. Deny an alert / defined policy.

app.links[0].deny()

3. Snooze an alert / defined policy / denied policy.

app.links[0].snooze()

Templates

Araali baselines your application communication and presents them as an identity-based policy recommendation which can then be accepted and converted to policy. This means no handwriting policies, everything is automatically discovered. Once these policies are accepted, they can also be enforced, which means only whitelisted communication will be allowed and the rest will be dropped.

Policies can be accepted per application using Araali UI or APIs. This works well for small to medium-sized applications but might seem tedious for a very large app. Araali allows the option to automate the acceptance of policies by leveraging templates. Templates are generally repeating patterns of communication seen in an application. Some of the examples could be

1. Backend talking to Databases

2. K8s nodes talking to control plane service

3. VMs in the cloud talking to metadata services and so on

These repeatable and known communication patterns can be translated into templates which helps with accepting the policies automatically without much user intervention.

Creating Templates

Templates can be created using APIs/UI. Users can choose to create declarative templates or convert an existing app’s policy links (suggested by Araali) to templates

App Links to a Template

Here are instructions to use templates.

In the image below the user chooses a link from Prometheus to the control plane service and clicking on the green save button takes us to the template editor.

In the editor the user can modify the selectors and it’s default values. This will be used to filter links that the user wanted to automatically convert to policies. The values specified here will be used in the policy selectors.

Once the user is satisfied with the selectors, they can name the template and also check the ‘Search and Use Continuously’ option at the bottom which will allow the user to start using the template. The user can choose to just save and turn on the template later as well.

A user can use araalictl API to accomplish the link to template conversion similar to the UI. The process starts by fetching links for a service or an app lens. Below is an example of fetching links for service. The command returns a list of links and the user picks out a link that they are interested in.

Given the link above the user runs ‘link-to-template’ command to convert the link to a template:

$ cat prometheus_link | ./araalictl api -link-to-template

- name: mufasa-k8s_monitoring.prometheus-operator.prometheus-operator_operator_to_10.100.0.1
  link_filter:
    client:
      zone: mufasa-k8s
      app: monitoring.prometheus-operator.prometheus-operator
      process: operator
    server:
      subnet: 10.100.0.1
      netmask: 32
      dst_port: 443
  use: false

If the user is satisfied with the above conversion they can accept it as is. If not, they can dump it to a file, edit, and then accept using the below command.

Accepting as is:

$ cat <policy_yaml> | ./araalictl api -update-template -use-link-template

Accepting edited template:

$ cat <edited_policy_yaml> | ./araalictl api -update-template

Sometimes a user might have an in-depth understanding of their app and might want to specify a declarative template. Some common examples, ‘snapd’ process on AWS EC2s talking to the Metadata Service (169.254.169.254:80), or the Kubelet talking to the coreDNS in a Kubernetes cluster.

Go to the template page and click on the “green plus button” to add a new template.

Once the template editor pops up, the user can choose the selectors they would like to use to filter links and accept them as policies (e.g., snapd talking to the MetaData Service below). Once satisfied, name the template, and check the option to “Search and use continuously” if they want to start using it right away. The user can choose to just save and turn on the template later as well.

The Araali APIs can take declarative policies in yaml format. Below is a sample yaml file:

$ cat meta.meta
- action: DEL
  name: amazonSsmAgentToMetadata
  link_filter:
    client:
      binary_name: /snap/amazon-ssm-agent/[0-9]+/amazon-ssm-agent
    server:
      subnet: 169.254.169.254
      netmask: 32
      dst_port: 80
  selector_change:
    client:
      binary_name: ^/snap/amazon-ssm-agent/[0-9]+/amazon-ssm-agent$
  use: true
- name: ingressHaproxy
  link_filter:
    client:
      subnet: 0.0.0.0
    server:
      process: haproxy
      binary_name: /usr/sbin/haproxy
  use: true
- name: snapdToSnapcraft
  link_filter:
    client:
      binary_name: /snap/core/.*/usr/lib/snapd/snapd
    server:
      dns_pattern: snapcraft.io|snapcraftcontent.com
      dst_port: 443
  selector_change:
    client:
      binary_name: ^/snap/core/.*/usr/lib/snapd/snapd$
  use: true
- name: ssmAgentWorkerToMetadata
  link_filter:
    client:
      binary_name: /snap/amazon-ssm-agent/[0-9]+/ssm-agent-worker
    server:
      subnet: 169.254.169.254
      netmask: 32
      dst_port: 80
  selector_change:
    client:
      binary_name: ^/snap/amazon-ssm-agent/[0-9]+/ssm-agent-worker$
  use: true
- name: kubeletToCoredns
  link_filter:
    client:
      zone: myk8s
      app: myapp
      binary_name: /snap/microk8s/\.*/kubelet
    server:
      zone: myk8s
      app: kube-system.coredns.coredns
      process: coredns
  selector_change:
    client:
      binary_name: /snap/microk8s/\.*/kubelet

There are three examples in the above yaml file.

1. amazonSsmAgentToMetadata - this is a non araali egress template. Non-araali servers are identified using dns_pattern or subnet/mask along with dst_port. This also shows an example of how to delete an existing template.

   This policy has an action as well and it is set to DEL, this helps with deleting templates that are already defined.

   snapdToSnapcraft - this is another example of non araali egress template where we are trying to match multiple fqdn patterns in link filter and trying to accept the links matching them.

2. ingressHaproxy - this is a non-araali ingress template. The non araali clients are identified using subnet and mask and if 0.0.0.0 is used it needs to have an endpoint group marker __WORLD__ or __HOME__ to narrow them down to public or private ip addresses. If not specified, the template will match both. In this example we have skipped using it.

3. kubeletToCoredns - this is an araali to araali template. The link_filter section has client and server selectors defined to select links that need to be accepted as defined policy. Once the links are selected, we use selectors from the link to create policies by default. If we need those selectors to be replaced by a different value, we can specify them in the selector_change section. In this example we want the binary_name selector to be replaced with the regex /snap/microk8s/.*/kubelet.

Note: Allowed selectors for Araali and Non-Araali endpoints.

Araali - “zone, app, process, binary_name, parent_process, dst_port”

Non-Araali Client - “subnet, netmask, endpoint group”

Non-Araali Server - “dns_pattern/(subnet, netmask), dst_port”

Note: Once defined, we need to start using the templates to accept links as defined policies. In the yaml we can set use: true like we have in ssm-agent-worker

API command to create templates:

$ cat <policy_yaml> | ./araalictl api -update-template

Defining templates only store it in the data store. In order to use it, to accept policies, a user has to set use boolean to true in the above yaml. Another way to use the template is to issue the start command with an explicit template name as shown below:

./araalictl api -template ingressHaproxy,snapdToSnapcraft -op use

Stop using Templates

Deleting Templates

Listing Templates

The above command dumps the existing policies and their state in yaml format.

Subscribing to Perimeter Egress:

./araalictl api -subscribe-for-alert -direction egress_world

Options for direction are: ingress_world|egress_world|ingress_home|egress_home|araali

Unsubscribing completely:

./araalictl api -unsubscribe-from-alert

Policy as Code

Provisioning Policies from Git

On every deployment of an app that needs to be secured, we can clean and apply policies that were saved in the git repo as part of ops for that app. This ensures that we always start from a clean state where we only allow the links that we have already reviewed and approved.

1. Generate and apply the Araali firewall installation yaml with the AraaliPolicy CRD enabled.

2. Modify the Service Discovery config to start watching Araali policy lifecycle.

   araalictl fortify-k8s -tags=zone=policy-1 -araali-policy-crd -force policy-1
   
   kubectl edit cm araali-operator-config -n araali-operator
   araalitags.operator.araali_k8s_policy_enable: "1" (Add this to configmap)
   
   kubectl apply -f araali_k8s.yaml
   

3. Apply the Araali policy from git before deploying application.

   kubectl apply -f /tmp/yaml/common.voting-tmp.yaml -n voting-tmp (K8S)
   cat /tmp/yaml/common.voting-tmp.yaml | araalictl policy -zone=policy-1 -app=voting-tmp -tenant=vmk -op update (VM)
   

4. Check UI for policy

   

With this workflow, Araali automates the task of writing network security policy and managing its lifecycle using git ops. After these policies are discovered, the app can use them on any cluster or even other clouds!

Pushing Policies to Git

Once we are satisfied with the review of the links for an app, we can fetch the links in yaml format using our command-line tool araalictl by following the steps below.

1. Download the reviewed and accepted policy for an application (rsncommon/voting)

   araalictl policy -zone=rsncommon -app=voting -tenant=rsn > /tmp/yaml/common.voting.yaml
   

2. Use the AKS voting app running in rsncommon zone and voting namespace.

   

3. Modify the zone, app and any other fields that need to be edited and save them into a different file. In this example the zone and app will be modified to (policy-1/voting-tmp)

4. Check your policy diff visually to make sure it is ok

   araalictl policy -file1 /tmp/yaml/common.voting.yaml -file2 /tmp/yaml/common.voting-tmp.yaml -op=diff
   

5. Note down the URL presented by the policy diff API. This is a persistant URL that can be passed around for policy review.

araalictl policy -diff-id=74c05743-a25c-45e4-8dd8-1f27956b690c

6. Commit the new policy file (/tmp/yaml/common.voting-tmp.yaml) to git along side the application.

We can repeat the discovery and review process to come up with good allowed policies. We should also be able to view the difference between policies in the file on the our git repo and the current status of links in the app, all on our UI.

Saving policies in git also help with versioning the policies which allow us to iterate over the discovery and review process.

Template as Code

In order to work with templates from the command line as opposed to the UI, there are a few commands we can use. Before you get started, make sure you are in the Python directory, and run:

./setup.sh

Commands

Config

The config command is the first command that should be used. It will specify the git directory:

# To specify directory for git
./template.py config -d=<git-directory>

List

The list command can be used to list the templates for a tenant:

# To access local templates
./template.py ls

# To access public templates
./template.py ls -p

Pull

The pull command can be used to make a copy of the public branch template into your local branch:

./template.py pull -p -T=<template-name-or-path>

# If no template is provided, defaults to all templates

Format

The format command is used to apply edits to the template:

./template.py fmt <template-path>

Push

The push command is used to push the local branch template to the public branch. NOTE: This is a dangerous command. Only run if you are confident in your changes to the template:

./template.py push -T=<template-name-or-path>

# If no template is provided, defaults to all templates

Drift

As edits are made to the templates, the local branch can start to differ slightly from the public one. The drift command can be used to check these differences:

./template.py drift -p -n -T=<template-name-or-path>

# If no template is provided, defaults to all templates

Alerts

The alerts command can be used to check any alerts:

./template.py alerts

Example Videos

Updating a Docker Template

Adding a New Link from UI to git

Setting up Araali Cloud Integration

1) In the Araali UI, go to “Cloud Integration” in the left-hand navigation panel.

2) Click the “+” icon on the top right, select your cloud provider, and enter your account id. Currently, Araali supports AWS only.

3) CLick on Download Yaml to download it on to your endpoint. Then click on “here” to open AWS cloud formation in another window to run this yaml file.

4. Upload the yaml file and go to next

5) Give a name to the stack. The rest of the default values are pre-populated, click next to proceed.

6) Click next for Step 3 and finally acknowledge the IAM disclaimer and submit for Stack Creation

7. Once the creation starts, go to the “Events” tab to check for completion

8) Go back to the Araali UI and now you will be able to see all the VPCs across all regions here (could take about 60 mins when you run it for the first time). It will list out the number of nodes in every VPC that is monitored and not monitored by Araali. You can turn on the lock to get an alert any time a node comes up without Araali on it.

Getting Alerts in Slack

Araali supports multiple channels through which customers can access their alerts. Slack is one of them. Slack alerts are sent using a webhook that can be configured using Araali APIs.

Creating a slack webhook URL

Here is a link to help with creating slack webhooks. The steps are (please follow the link for latest from slack directly):

1. Create a new Slack app in the workspace (araali - in the example below) where you want to post messages.

2. From the Features page, toggle Activate Incoming Webhooks on.

3. Click Add New Webhook to Workspace.

4. Pick a channel that the app will post to, then click Authorize.

5. Use your Incoming Webhook URL to post a message to Slack.

This is a sample slack application using which we show how to configure webhooks for “araali” workspace. The webhook URL is created as part of the application and we’ve chosen a slack channel on which we will receive notifications.

Configure slack webhook URL

Once we have the webhook ready we can use araalictl api to configure the webhook so that we can start receiving araali alerts on a slack channel:

./araalictl api -update-webhook -webhook <webhook_url>

Subscribing to Alerts

We can subscribe to alerts for a lens we are interested in using araali UI as below.

A user can subscribe to alert notifications. Anytime, a new alert is seen by the system an email will be generated. With time as the app is discovered, new alerts should reduce (only infrequent communications will trigger new alerts).

Security Professionals can subscribe for all alerts related to perimeter egress or ingress across all apps.

Finally, we should start receiving alerts on the slack channel that we configured.

Remapping Apps

Araali uses convention to discovers apps in your k8s environment. As best practice, apps are deployed in their own namespace. There is no good reason to actually not do so.

However, due to team isolation, sometimes namespaces are pre-created by the infrastructure team and kept small by design (to prevent proliferation and also to keep the privileges for namespace management limited to a smaller team).

For e.g. some people could have static namespaces that denote environments instead of apps (prod, staging, dev). In other cases, namespaces could be created per team for isolation (team1, team2). If teams map to features/apps, then there is not much of an issue. However, a single team could be responsible for multiple logical apps and the namespace itself ends up becoming a container for these apps.

For such scenarios Araali allows you to customize apps the way you understand it, regardless of which namespace they will show up in.

Remapping Using Pod Label Key

If your pods already have a label that represents your desired app remap structure, then App Remapping can be easily accomplished via the UI.

Click and select “App Remap” and then click on the “+” icon on the top right corner.

This will open “Add Pod Label” where you can select the zone/cluster, app/namespace that you want to remap. Pass the Pod Label Key for Araali to pull the information from the Pod metadata and remap your app.

Or, do it using code:

// List existing App-Mapping Based on Pod-Label
$ ./araalictl app-mapping -op list
- zone: nightly-k8s
app: nightly-bend
label: app

// Create Yaml file with zone, app that needs to be remapped and the label to be used for remapping.
Create a new file: app_remap.yaml

- zone: test-zone
  app: test-app
  label: app

// Add new pod label based app remapping
$ cat app_remap.yaml | ./araalictl app-mapping -op add
{"success":true}
$ ./araalictl app-mapping -op list
- zone: nightly-k8s
  app: nightly-bend
  label: name
- zone: test-zone
  app: test-app
  label: app

// Delete existing pod label based app remapping
$ cat app_remap.yaml | ./araalictl app-mapping -op del
{"success":true}
$ ./araalictl app-mapping -op list
- zone: nightly-k8s
  app: nightly-bend
  label: app

App (Re)mapping Using podName

This is a sample google shop application where all the pods show up under a single app - gshop. We’ll walk through the process of splitting this up into three different apps.

List all the apps to pod mapping as a yaml file

$ ./araalictl api -list-pod-mappings > pod_mapping.yaml

Update the mapping yaml file

1. We delete the pods we don’t want to remap.

2. As we can see we have the app and namespace set to the same value.

3. Now we reset the app to the name we would like to see it as.

This can be done programmatically as well. Here we show a manual way of editing the yaml files.

Below is a sample yaml file generated. Now we would like to re-map the pods as below.

frontend → gshop-frontend

redis-cart → gshop-db

rest of the services → gshop-service

Here is the code:

$ vi pod_mapping.yaml
- zone: prod
  namespace: gshop
  pod: checkoutservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: frontend
  app: gshop
- zone: prod
  namespace: gshop
  pod: cartservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: recommendationservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: currencyservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: shippingservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: adservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: redis-cart
  app: gshop
- zone: prod
  namespace: gshop
  pod: productcatalogservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: emailservice
  app: gshop
- zone: prod
  namespace: gshop
  pod: paymentservice
  app: gshop

Edited yaml file (with changed app):

$ vi pod_mapping.yaml
- zone: prod
  namespace: gshop
  pod: checkoutservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: frontend
  app: gshop-frontend
- zone: prod
  namespace: gshop
  pod: cartservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: recommendationservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: currencyservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: shippingservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: adservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: redis-cart
  app: gshop-db
- zone: prod
  namespace: gshop
  pod: productcatalogservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: emailservice
  app: gshop-service
- zone: prod
  namespace: gshop
  pod: paymentservice
  app: gshop-service

Update the pod to app mapping in araali

$ cat pod_mapping.yaml | ./araalictl api -update-pod-mappings

Once the above exercise is complete we can see that a single app before got split into three different apps as below.

Programmatic Mapping by Example

This can also be programmatically achieved using our python APIs. The transformations should ideally be idempotent so they can be rerun without issues:

mapping = araalictl.get_pod_apps()

if (obj["zone"] == "nightly-k8s" and
    obj["namespace"] == "nightly-bend" and
    "pod" in obj):

    if obj["pod"] in ["flowstitcher", "flowprocessor",
                      "assetinfo-processor",
                      'applens-generator',
                      "applens-compactor",
                      "vulnscanner"]:

        obj["app"] = "nightly-bend-pipeline"

araalictl.push_pod_apps(mapping)

Functions

Get

Get all Mapping content.

Command LinePython

./araalictl app-mapping -op list

Add

Add to mapping content.

Command LinePython

# "i" to insert at cursor, "a" for after cursor, and "o" for line above cursor
vi add_mapping.txt
# Insert zone, app, label in yaml format
# Esc to exit edit mode in vi
# “:wq” to quit once in control mode
cat add_mapping.txt | ./araalictl app-mapping -op add

Remove

Remove from mapping content.

Command LinePython

# "i" to insert at cursor, "a" for after cursor, and "o" for line above cursor
vi add_mapping.txt
# Insert zone, app, label in yaml format
# Esc to exit edit mode in vi
# “:wq” to quit once in control mode
cat add_mapping.txt | ./araalictl app-mapping -op del

FAQ

What is Araali

Araali transparently wraps any application without requiring any change such that it is assigned a stable identity via our distributed trust fabric, that also controls all communication attempts between them.

Our least privilege policies are automatically discovered with a single click install that requires no config and comes with a do no harm guarantee.

This is particularly useful for cloud native where applications are spun up dynamically and are often ephemeral. The identity based policies are location and IP independent, making them reusable post discovery.

MTLS vs Araali

MTLS is primarily giving you data in flight encryption. The certificates are tied to infrastructure elements like nodes, IPs and Pods, not to the transport endpoints. A malware behind the pod enjoys the same privilege. Moreover, there is also authorization to do once identity is established. Araali makes auto discovery of least privilege communication policies a breeze and enforces it too.

Service Mesh vs Araali

Service mesh helps with service discovery, load balancing and circuit breaking. Araali does not offer any of these functions. Service mesh also offers security policy. However these are at pod/IP level and any malware sitting behind the IP enjoys the same privilege. Moreover, Araali makes policy discovery a breeze. These policies are portable and permanent and enjoy the same lifecycle as the app itself.

Privacy Policy

We care about your privacy!

Compliance via API

Overview

Araali also allows you to fulfill your SOC2 compliance requirements. Some of the areas where Araali can help fulfill the SOC2 compliance requirements are:

1. Visibility into your Assets - VMs and Containers

   • get_compute()

The get_compute API is very rich and has information on both Assets as well as corresponding CVEs

2. Vulnerability List based on your VMs and Containers

   • get_compute()

3. Compensating control for Vulnerability - Araali Shielding

   • get_lenses(enforced=True)

In SOC2 you have to show compensating control for known vulnerability. Araali allows you to shield your vulnerable Apps or Containers to fulfill this obligation. This API gives a list of Zones and Apps that have been shielded/enforced. Using this API with the output of get_compute(), you can understand which assets have been Araali Shielded.

4. Alerts generated - Intrusion Detection

   • get_alerts()

This API gives you a list of Alerts that were generated in a given period of time.

5. Users who have access to Araali and their assigned Roles

   • rbac_show_users()

This API gives a list of users along with their assigned role.

6. Proactively Shielded Apps - Intrusion Prevention

   • get_enforced_links()

Araali Shielding is similar to Application Firewall as it enforces both incoming and outgoing traffic from your assets. Once Shielded, Araali will not let your application deviate from these baseline policies making them unexploitable. These are enforced processes belong to a certain Zone/Cluster and App/Namespace which can be tabulated with this API.

For SOC2 Type2 compliance a customer has to show that they have ongoing security controls in place and it can be proved via periodic capture of evidence. To prove the above controls Araali can take periodic snapshots of all the items above, and put it in a report that can be used by the auditor.

Python Usage

1. Fork the open source `Github Repo<https://github.com/araalinetworks/api>`_

2. Download the fork to your local machine

3. Navigate to the fork through command line

4. Run Python in the command line

Commands

To specify tenant through the command line, use the -t or --tenant flags. To do so through Python, use the tenant argument.

get_compute()

Gets computes for a specific zone-app

Command LinePython

./araalictl api -zone <zone> -app <zone> -fetch-compute

get_lenses(enforced=True)

Gets all enforced lenses for the tenant (if specified)

Command LinePython

./araalictl api -fetch-enforcement-status -enforced

get_alerts()

Gets all alerts for the tenant (if specified).

Command LinePython

# use -starttime and -endtime to specify start and end times (epoch)
./araalictl api -fetch-alerts -paging-token <token> -count <count>

rbac_show_users()

Gets all current users for tenant (if specified)

Command LinePython

./araalictl user-role -op list-user-roles

get_enforced_links()

Gets enforced links for tenant (if specified)

Command LinePython

# This command uses multiple other Python wrapper commands, making a command line execution difficult

Golang SDK API

Functions

Must import api/api for all functions to work

TenantCreate()

Create a tenant

Go

api.TenantCreate(name, adminName, adminEmail string, freemium bool)

TenantDelete()

Delete a tenant

Go

api.TenantDelete(tenant string)

UserAdd()

Add a User

Go

api.UserAdd(tenant, userName, userEmail, role string)

UserDelete()

Delete a User

Go

api.UserDelete(tenant, userEmail string)

ListAssets()

Get assets

Go

api.ListAssets(tenant, zone, app string, activeVm, inactiveVm, activeContainer, inactiveContainer bool, startTime, endTime time.Time)

ListAlerts()

Get alerts

Go

api.ListAlerts(tenant string, filter *araali_api_service.AlertFilter, count int32, pagingToken string)

ListLinks()

Get links within a zone/app

Go

api.ListLinks(tenant, zone, app, service string, startTime, endTime time.Time)

ListInsights()

Get tenant wide insights

Go

api.ListInsights(tenantID, zone string

REST APIs

REST APIs are protected by tokens that need to be passed by the client making these requests.

To generate the token, go to Admininstration - API Tokens.

Click on + to create a new token.

Copy generated token and keep it in a safe store.

The token can be revoked at anytime.

Follow the API calls below to get specific information required for compliance

Assets

Lists out all the assets - VMs and containers, along with vulnerabilities. Also includes inactive assets that were previously live but are no longer running.

https://api-prod.aws.araalinetworks.com/api/v2/listAssets?tenant.id=<tenant-id>&filter.time.start_time=2021-05-05T16:47:00.000Z&filter.time.end_time=2023-05-05T16:57:00.643Z&filter.list_active_vm=1&filter.list_active_container=1&filter.list_inactive_vm=1&filter.list_inactive_container=1

Enforced Lens

List of containers or VMs where Araali FW is enabled. This is to show that

compensating controls and IPS exist for vulnerable containers.

https://api-prod.aws.araalinetworks.com/api/v2/listShieldedLens?tenant.id=<tenant-id>

Alerts

List of open and closed alerts. This is to show that you have IDS enabled for your cluster.

https://api-prod.aws.araalinetworks.com/api/v2/listAlerts?tenant.id=<tenant-id>&filter.time.start_time=2023-05-03T16:57:00.643Z&filter.time.start_time=2023-05-05T16:57:00.643Z&filter.list_all_alerts=1&filter.open_alerts=1&filter.closed_alerts=1&filter.perimeter_egress=1&filter.perimeter_ingress=1&filter.home_non_araali_egress=1&filter.home_non_araali_ingress=1&filter.araali_to_araali=1&count=20

List Insights

This is the list of critical assets in your infrastructure like internet-exposed assets, databases, high-privilege assets, potential backdoors, and many more.

https://api-prod.aws.araalinetworks.com/api/v2/listInsights?tenant.id=<tenant-id>

Getting Started with AWS EKS

Install AWS EKS with eksctl

Skip this part and go to “Test if you have access” if you have already installed or have access to an AWS EKS cluster and a functioning kubectl on your local machine.

Install eksctl by following instructions in this doc

This is a good way to choose Ubuntu AMI for the node machine. The console approach does not allow you to launch Ubuntu AMI.

Create a cluster and Nodes

This will create a cluster using Ubuntu AMI. If you don’t choose an AMI it will pick AmazonLinux:

eksctl create cluster --node-ami=Ubuntu1804

This will attach node groups to the cluster:

eksctl create nodegroup --cluster=floral-sculpture-1600963464 \
     --name=testu --node-ami-family Ubuntu1804  --node-volume-size=45 \
     --ssh-public-key="~/.ssh/key1.pub"

Access your cluster

After the k8s cluster and nodes are created (either through CLI or console), the next step is to access it:

aws eks --region us-west-2 update-kubeconfig --name k8s-test-cluster

This will add cluster information to kubectl config file generally sitting in /home/ec2-user/.kube/config

Test if you have access to the cluster

kubectl get svc -A

Check which cluster you are connected to:

kubectl config current-context

Install Araali

Follow the instructions in the getting started post

Setting up an app to test

Download the google-microservice-shopping app from GitHub:

git clone https://github.com/GoogleCloudPlatform/microservices-demo.git

Go to the directory:

cd microservices-demo/release

Create a namespace:

kubectl create ns gshop

Run the file:

kubectl apply -f kubernetes-manifests.yaml --namespace=gshop

Get the IP for external service to log from a browser:

kubectl get svc -A

FrontEnd

Getting Started with GKE/AKS

Requirements

You should have access to a cluster on GKE and a functioning kubectl on your local machine.

You can validate your kubectl by running:

kubectl version --short

Check if kubectl is pointing to the cluster you want to assess:

kubectl get svc

Install Araali and start the assessment

Follow the instructions in the getting started post

Once Araalictl is set up, start the assessment:

./araalictl assessment -start

Setting up an app to test

Download the google-microservice-shopping app from GitHub:

git clone https://github.com/GoogleCloudPlatform/microservices-demo.git

Go to the directory:

cd microservices-demo/release

Create a namespace:

kubectl create ns gshop

Run the file:

kubectl apply -f kubernetes-manifests.yaml --namespace=gshop

Get the IP for external service to log from a browser:

kubectl get svc -A

FrontEnd

Stop the assessment

After running the tests, you can stop the assessment:

./araalictl assessment -stop

Freemium only allows you to run point-in-time assessments (vs continuous monitoring/security). So as long as your tests complete in a reasonable time, you should have a good picture of your application

Getting Started with microk8s (Ubuntu)

This is an end-to-end guide on how to test Araali on Canonical’s MicroK8s and use an opensource microservice app (sockshop).

Install MicroK8s

Start with a VM running Ubuntu. For demonstration purposes, Ubuntu 21.10 is used here. Install MicroK8s with the following command to get periodic snap updates of Microk8s to ensure compatibily with newer Ubuntu releases:

sudo snap install microk8s --classic --channel=latest/stable

Join the Group

sudo usermod -a -G microk8s $USER sudo chown -f -R $USER ~/.kube

Exit and log back to the VM

Check if microk8s is up

microk8s status --wait-ready

If the above command does not return any output, it is likely that an error occured. Remove the same command without the --wait-ready flag to know any errors and/or warnings.

Create a link/alias

sudo snap alias microk8s.kubectl kubectl

Now use mkctl like kubectl. If you DONT want the alias then use “microk8s.kubectl” command similar to “kubectl”

Enable the dns and ingress services

microk8s enable dns

microk8s enable ingress

Install Araali and start the assessment

Follow the instructions in the getting started post

Install an Opensource App

Download sock-shop from Github

git clone https://github.com/ashish234/sock-shop.git

Create a namespace

mkctl create ns sock-shop

Deploy the yaml file

mkctl apply -f sock-shop/sock-shop.yaml -n sock-shop

Look into the services and mark the port for NodePort service “front-end”

In this case its running on 30001

Open a browser and type your VM’s IP:30001

Getting started with microk8s (Mac)

This is an end-to-end guide on how to test Araali on Canonical’s MicroK8s and use an opensource microservice app (sockshop). The most important thing is to ensure things are running at every stage before you can proceed to the next.

Install MicroK8s using Homebrew

Install Homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Once Homebrew is installed, you can proceed with Microk8s

Install MicroK8s

brew install ubuntu/microk8s/microk8s

microk8s install

Note: Say yes to multipass install (above)

Check if microk8s is up:

microk8s status --wait-ready

Before installing dns and storage, ensure the cni is up and running by executing:

microk8s kubectl get pods -A

Enable the dns and ingress services:

microk8s enable dns

microk8s enable ingress

Before proceeding further, ensure dns and ingress are up and running by executing:

microk8s kubectl get pods -A

Install Araali

Follow the instructions in the getting started post

Installing an Opensource App

Download sock-shop from Github:

git clone https://github.com/ashish234/sock-shop.git

Create a namespace:

microk8s kubectl create ns sock-shop

Deploy the yaml file:

microk8s kubectl apply -f sock-shop/sock-shop.yaml -n sock-shop

Look into the services and mark the port for NodePort service “front-end”:

microk8s kubectl apply get svc -n sock-shop"

In this case its running on 30001

Open a browser and type your VM’s IP:30001

Getting started with minikube (Mac)

Minikube is a tool to setup a single node Kubernetes cluster. We will setup a single node cluster with the VirtualBox driver.

Install Minikube

Install Minikube using Homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Once Homebrew is installed, you can proceed with Minikube

brew install minikube

If which minikube fails you may have to remove the old minikube links and link the newly installed binary.

brew unlink minikube
brew link minikube

Install Minikube from binary

For X86:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
sudo install minikube-darwin-amd64 /usr/local/bin/minikube

For ARM:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-arm64
sudo install minikube-darwin-arm64 /usr/local/bin/minikube

Install VirtualBox

brew install --cask virtualbox

Get the 4.19.94 based minikube.iso

Get the iso from s3://araalinetworks.cf/minikube.iso to /tmp/minikube.iso:

curl -o /tmp/minikube.iso https://s3-us-west-2.amazonaws.com/araalinetworks.cf/minikube.iso

Start the Minikube Kubernetes cluster

minikube start --iso-url=file:///tmp/minikube.iso --driver=virtualbox

Check status

minikube status

kubectl get pods -A

Deploy an application

kubectl create ns guestbook
kubectl apply -n guestbook -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/guestbook-all-in-one.yaml

Check the status

Getting Started with SIEM Integration

This is a guide on how to integrate Araali with supported SIEM products

Install Araali

Follow the instructions in the getting started post

This sets up and authorizes Araalictl for local use.

Integration with ElasticStack

Configure the TCP input plugin to accept json data. Open the existing LogStash config file and add the following to the input plugin list.:

input {
  tcp {
    port => 9099
    codec => "json"
  }
}

Restart the LogStash service for the configuration to take effect.

sudo systemctl restart logstash

Check netstat to make sure LogStash has started listening on the chosen port.

sudo netstat -lntp | grep 9099

Start Araali Collector

Start the Araali Collector to submit Araali data to the configured LogStash TCP input port.

./araalictl api -stream-start -stream-tcp=0.0.0.0:9099 -out=json -stream-cnt=1000

Check status

./araalictl api -stream-status

Sentinel Integration

Install logstash on a VM .:

$ wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
$ sudo apt-get install apt-transport-https
$ echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
$ sudo apt-get update && sudo apt-get install logstash

Install Azure Sentinel Plugin for Logstash on the vm .:

$ sudo /usr/share/logstash/bin/logstash-plugin install microsoft-logstash-output-azure-loganalytics

Figure out workspace id, primary key from Azure log analytics workspace settings as below

Add workspace key to logstash keystore and then create logstash config as below. Finally, restart logstash .:

$ sudo mkdir -p /usr/share/logstash/config
$ sudo /usr/share/logstash/bin/logstash-keystore create
$ sudo /usr/share/logstash/bin/logstash-keystore add WS_KEY

$ cat /etc/logstash/conf.d/araali_sentinel.conf
input {
  tcp {
    port => 9099
    codec => json
  }
}
output {
  microsoft-logstash-output-azure-loganalytics {
    workspace_id => "<your_workspace_id>"
    workspace_key => "${WS_KEY}"
    custom_log_table_name => "araaliAlertsTable"
    plugin_flush_interval => 5
  }
}

$ sudo systemctl restart logstash.service

Now start araalictl stream to fetch alerts .:

./araalictl.linux-amd64 api -stream-start -stream-tcp=0.0.0.0:9099 -out=json -stream-cnt=100

Then we should be able to see the logs getting ingested under our workspace in azure sentinel > logs > tables tab

Useful links

https://www.elastic.co/guide/en/logstash/current/installing-logstash.html https://www.elastic.co/guide/en/logstash/7.14/running-logstash.html https://docs.microsoft.com/en-us/azure/sentinel/connect-logstash https://github.com/Azure/Azure-Sentinel/tree/master/DataConnectors/microsoft-logstash-output-azure-loganalytics https://www.elastic.co/guide/en/logstash/current/working-with-plugins.html https://www.elastic.co/guide/en/logstash/current/keystore.html

Getting Started with Kubernetes

Supported/Verified Managed Cloud K8s

1. AWS EKS - AmazonLinux (default) and Ubuntu node VMs

2. GCP GKE - CoS (default) and Ubuntu node VMs

3. Azure AKS - Ubuntu running default Kubernetes (v1.18) or later.

4. Canonical MicroK8s

5. RancherD

Prerequisites

1. Cluster should have egress port 443 open to allow Araali to talk to the backend.

Araali UI Login

1. Open a chrome browser and go to Araali Console

2. If your email is already registered and your business email uses Google service, then use “Sign in with Google”. Otherwise, click on “Need Help Signing In?” which will open “Forgot Password?”. Then, complete the steps to sign in to the console.

3. You are in!!

4. Now, in the left-hand panel, go to Administration and then Araali Tools. You have to come back to this page to authorize Araalictl

Fortifying a k8s Cluster

Follow the steps below to fortify a Kubernetes cluster (same place where your k8s control plane is running).

1. Download Araalictl

   On Linux:

   curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.linux-amd64
   

   On Mac:

   curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.darwin-amd64
   

2. Make it executable:

   chmod +x araali*
   ln -sf araali* araalictl
   

3. Authorize araalictl:

   sudo ./araalictl authorize <email-id>
   

4. Now go to Araali UI >> Administration >> Araali Tools to approve the araalictl session.

5. Check if araalictl is installed:

   ./araalictl version -v
   

6. Check current context, the name with “*” is the one you are pointing to right now:

   kubectl config get-contexts
   

7. Fortify your cluster, araalictl and kubectl running on the same machine:

   ./araalictl fortify-k8s -auto -tags=zone=<optional-zone-override> -context=<context of k8s cluster>
   

Optional: If araalictl and kubectl are not running on the same machine:

# Create yaml file to fortify your cluster
./araalictl fortify-k8s -tags=zone=<optional-zone-override> -context=<context of k8s cluster>
# The above command will generate araali_k8s.yaml file. Copy it to the k8s control plane (where kubectl is running) and then apply
kubectl apply -f araali_k8s.yaml

Check if Araali is Installed

Araali should be running in two namespaces (1) araali-operator and (2) kube-system:

kubectl get pods -A

Setting up Araalictl in the CM VM

1. Download Araalictl

   Linux:

   curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.linux-amd64
   

   Mac:

   curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.darwin-amd64
   

2. Make it Executable:

   chmod +x araali*
   ln -sf araali* araalictl
   

3. Authorize Araalictl:

   sudo ./araalictl authorize <email-id>
   

4. Check if Araalictl is installed:

   ./araalictl version -v
   

5. Optional - Generate and add ssh-key (if Araalictl is running on the VM you wish to fortify)

6. If you don’t have id_rsa.pub in your ~/.ssh account:

   ssh-keygen
   

7. Copy it to authorized_keys to allow ssh localhost:

   cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
   

Fortifying target VMs in your Cluster

• Fortifying Remotely:

  ./araalictl fortify-live -fortify -tags=zone=<zone_name>,app=<app_name> vm1
  

• Fortifying Localhost:

  ./araalictl fortify-live  -fortify -tags=zone=<zone_name>,app=<app_name> localhost
  

• Updating Zone, App tags:

  ./araalictl fortify-live -add -tags=zone=<updated_zone>,app=<updated_app> <remote_user>@<remote_host>
  

For wider use, we recommend to run Araali on the same machine as your Configuration Management Tool (Ansible, Salt, Puppet, Chef, etc.)

Sample K8s Microservice to Test

Google Cloud Platform eCommerce Demo Clone from Github:

git clone https://github.com/GoogleCloudPlatform/microservices-demo.git

1. Create namespace or run it in default namespace:

   kubectl create ns gshop
   

2. Run the microservice:

cd microservices-demo/release kubectl apply -f kubernetes-manifests.yaml -n gshop

3. get URL of the frontend:

kubectl get svc -A

Araali Dashboard

Go back to the Araali UI and click dashboard. You can see an inventory of your assets covered as well as detailed audits of your communication.

To Uninstall Araali

To uninstall if araalictl and kubectl are on the same machine:

./araalictl fortify-k8s -delete -context=<context of k8s cluster>

Otherwise, delete the yaml file:

kubectl delete -f araali_k8s.yaml

To Uninstall Remotely:

./araalictl fortify-live -unfortify <remote_user>@<remote_host>

To Uninstall Locally:

./araalictl fortify-live -unfortify localhost

Getting Started with Rafay

Prerequisites

1. Registered with Rafay and account created

2. Register with Araali to create an account to:

   • Access the UI dashboard

   • Install araalictl and authorize it

   • Help with generation of Helm values.yaml

Araali UI Login

1. Open a chrome browser and go to [Araali Console](https://console.araalinetworks.com)

   

&nbsp;

2. Click Sign Up to register

3. You are in!!

4. Now, in the left-hand panel, go to Administration and then Araali Tools. You will use this page to authorize Araalictl

   

Generating Helm values.yaml

__Follow the steps below to generate a values.yaml file to use with Araali Helm chart for your cluster.__

### Setup

1. Download Araalictl * On Linux

   `console curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.linux-amd64 `

   • On Mac

     `console curl -O https://s3-us-west-2.amazonaws.com/araalinetworks.cf/araalictl.darwin-amd64 `

&nbsp;

2. Make it executable `console chmod +x araali* ln -sf araali* araalictl `

3. Authorize araalictl `console sudo ./araalictl authorize <email-id> `

&nbsp;

4. Now go to Araali UI >> Administration >> Araali Tools to approve the araalictl session. 

### Execution

1. Check if araalictl is installed

   `console ./araalictl version -v `

&nbsp;

2. Generate helm values::

   `console ./araalictl fortify-k8s -out=helm > /tmp/values.yaml `

Create Rafay Repository for Araali Helm chart access

Add Araali Helm repository to Rafay - [Create Rafay Araali Helm Registry](https://console.rafay.dev/#/app/repositories)


The Rafay repository will be used in the Araali addon below

Create Rafay AddOn for Araali Firewall

Add Araali addon to Rafay - [Create Rafay Araali AddOn](https://console.rafay.dev/#/app/addons)

1. Click on New AddOn 

&nbsp;

2. Click on New Version 

&nbsp;

3. Upload the previously created values.yaml file `console Chart Name: araali-fw Chart Version: 1.0.0 `

&nbsp; 4. Edit the values.yaml in Rafay to get the runtime clustername from Rafay.


The Rafay addon will be used in the Araali Blueprint below

Create Rafay Blueprint that uses Rafay AddOn

Add Araali blueprint to Rafay - [Create Rafay Araali Blueprint](https://console.rafay.dev/#/app/blueprints)

1. Click on New AddOn 

&nbsp;

2. Click on New Version 

&nbsp;

3. Use the addon created above in the add AddOn section

This blueprint will be applied to the cluster

Enable Rafay Blueprint on the cluster

Add Araali Blueprint to Rafay - [Create Rafay Araali Blueprint](https://console.rafay.dev/#/app/blueprints>)

1. Click on the settings wheel icon and select Update Blueprint 

&nbsp;

2. Pick the Blueprint and Version created in previous step 

&nbsp;

Once the changes are saved, the Araali add on is __activated in the cluster__. Check for the sync to finish and visit the Araali Dashboard for instant visibility into your cluster.

Araali Dashboard

Go back to the Araali UI and click dashboard. You can see an inventory of your assets covered as well as detailed audits of your communication.


Uninstalling Araali

Select the default blueprint and apply it to the cluster

Guide for Templates

Overview

There is a marketplace for shareable App policies. In the UI sidebar, there is a section labeled “Templates”. Araali has started publishing public templates for well-known apps starting with Araali apps. Private templates can be created to auto-approve based on pattern matching, and user contribution to the marketplace will be possible in the future (today the public policies are Araali-controlled).

These templates are not acted upon by default; they are only intended for people who want to cruise control by putting the approval process on auto-pilot (this is based on published and community-reviewed App patterns). These templates can be stopped with the click of a button. It is also possible to do all of this with APIs.

Enabling the “araalifw-kube” template will auto-approve all Araali links and suppress any alerts coming from Araali’s app (Daemonset/Operator).

Please note that the public template for Araali is still being tested internally. It should be safe for use: it just may not be comprehensive or complete yet.

Guide for Araali SW Template

Araali baselines your application communication and presents them as identity-based links that can then be accepted as policy. This means no handwriting policies, everything is automatically discovered.

One of the easier ways to accept policies is through UI Templates. Araali has published a template for its own software in the “Public” folder that can be used to auto-accept Araali’s own policies.

When to use Templates

Templates are particularly useful when:

• You are an app owner and want to publish your app’s profile into a marketplace that anyone can use and benefit from. Ideally you want to publish to the marketplace whenever there are app changes that necessitate a refresh.

• You have common patterns that apply across app/service lenses. You can define patterns in template once, and apply it across lenses to do the greening/policy-accepting based on pattern matching.

• You want to edit/customize a node (say use .* as regex for the pid in snapd binaray path). You can alternatively select links and edit them individually (repeating the editing to put the .* on a per link basis). The benefit of using template is that you can edit a node once, and add new links to the template. The node editing is automatically inherited as you add a link to an existing template. This is only available via api currently. We are trying to get it to UI sometime soon.

Applying Araali Template in UI

In the Araali UI, go to the Public Template and click on the download icon next to “araalifw-kube” template.

This will open a window. The template is very flexible and allows you to further customize using regex. We recommend that you use the template as is. You can change the name of the template, check the box “search and use continuously” and then save the template.

This will instantiate a local copy of the template in your “Private” folder. If you go to the folder you can see the template running. If you want to stop the template, you can click on the orange stop button.

Now if you go back to your kube-system app and refresh the page, you will see all the links from araali-fw pod green.

Programmatic Manipulation

Get

Get all templates. It is possible to optionally filter for public templates or access a specific template.

Command LinePython

# Get all templates
./araalictl api -list-templates

# Get only public templates
./araalictl api -list-templates -public

# Specify a template
./araalictl api -list-templates -template=<template>

Rename

Rename an existing template

Command LinePython

# Copy the output of the following
# Use existing template name
./araalictl api -list-templates -template=<old_template>

# "i" to insert at cursor, "a" for after cursor, and "o" for line above cursor
vi edit_template.txt
# Paste previously-copied output
# Change existing name to desired name
# Esc to exit edit mode in vi
# “:wq” to quit once in control mode
cat edit_template.txt | ./araalictl api -update-template -template=<old_template>

Save

Save a link as a template

Command LinePython

# Fetch links for desired zone-app
./araalictl api -fetch-links -zone z_name -app a_name
# Copy desired link(s)
# "i" to insert at cursor, "a" for after cursor, and "o" for line above cursor
vi za_template.txt
# Paste previously-copied link(s)
# Esc to exit edit mode in vi
# “:wq” to quit once in control mode

# Add "-use-template-link" to Search and Use Continuously
#
cat za_template.txt | ./araalictl -save-link-template

Guide to Lenses

Overview

Securing everything is a euphemism for securing nothing, or at best doing best-effort security.

Instead, confidently and precisely secure what matters, even in the light of an intruder within the premises. Zero Trust performs security the way the Secret Service protects the President of the United States. At any point, they need to know who the President is, where they are at all times, and who has access to them at all times. It’s about identifying the protect surface, lensing concern, and creating focus.

Lenses are the minimum yet completely self-contained units that can be owned, reviewed, monitored, and enforced. They can either be applications that Araali protects, or services that are used by Araali-protected clients. By lensing concern, it is possible get to focus on one app or service at a time, wherever the concern may lie.

Turning enforcement on for an Araali-protected app means that only authorized clients can use the services offered by the app (ingress). Should the app be compromised by an intruder, it won’t pollute the environment or move laterally (egress), or even gain access to services that are internal to the app (internal).

Turning enforcement on for a service lens means that only approved apps from all Araali-protected assets can ever access the service. If there is an intruder within the Araali-protected environment, it doesn’t get the same access to the service, as your own legitimate apps would. A service, by definition, is third-party, and Araali does not have presence in it. Therefore, the enforcement happens on the client side, and it makes sure that only the correct identities get to access an external service from within your environment.

But before getting into enforcement, it is important to first identity what lenses are worth spending time on. It is possible to pin important lenses to the dashboard, check the enforcement status, and toggle enforcement on or off using the APIs.

Functions

Get

Get all Lenses along with owner info (if available). It is possible to optionally get only enforced lenses or only starred lenses.

Command LinePython

# get all lenses along with their enforcement status
./araalictl api -fetch-enforcement-status

# use -enforced flag to fetch only enforced lenses
./araalictl api -fetch-enforcement-status -enforced

# use a seperate command to fetch only starred lenses
./araalictl api -fetch-starred-lens

Star

Star Lens.

Command LinePython

# star zone-app lens
./araalictl api -zone=<zone> -app=<app> -star-lens

# star service lens
./araalictl api -service=<fqdn/ip:port> -star-lens

Unstar

Unstar all currently starred Lenses. It is like performing a factory reset and clearing the Araali dashboard.

Command LinePython

./araalictl api -clear-starred-lens

Monitor

Monitor a lens. You start getting emails when there is new activity in the lens

Command LinePython

# subscribe to zone-app lens alerts
./araalictl api -zone=<zone> -app=<app> -subscribe-for-alert

# subscribe to service lens alerts
./araalictl api -service=<fqdn/ip:port> -subscribe-for-alert

# subscribe to directional alerts
./araalictl api -subscribe-for-alert -direction ingress_world, egress_world

Unmonitor

Stop monitoring a lens. You stop getting emails for the lens

Command LinePython

# unsubscribe from zone-app lens alerts
./araalictl api -zone=<zone> -app=<app> -unsubscribe-from-alert

# unsubscribe from service lens alerts
./araalictl api -service fqdn/ip:port -unsubscribe-from-alert

Monitor Perimeter

Monitor all lenses for alerts. You start getting emails when there are new alerts.

Command LinePython

# subscribe to world alerts
./araalictl api -subscribe-for-alert -direction ingress_world,egress_world

Unmonitor Perimeter

Unmonitor all lenses for alerts. You will stop getting emails when there are new alerts.

Command LinePython

# unsubscribe from world alerts
./araalictl api -unsubscribe-from-alert -direction ingress_world,egress_world

Enforce

Enforce Lens.

Command LinePython

# "i" to insert at cursor, "a" for after cursor, and "o" for line above cursor
# input the following
vi enforce_za.txt

# for zone-app:
- zone_name: string
  apps:
  - app_name: string
    ingress_enforced: True
    egress_enforced: True
    internal_enforced: True

# for service:
- dns_pattern: fqdn/ip
  dst_port: port
  new_enforcement_state: ENABLED

# Esc to exit edit mode in vi
# “:wq” to quit once in control mode

# for zone-app
cat enforce_za.txt | ./araalictl api -enforce-zone-app

# for service
cat enforce_za.txt | ./araalictl api -enforce-service

Unenforce

Unenforce Lens.

Command LinePython

# follow steps for enforce
# but change True values to False
# and "ENABLED" to "DISABLED"

Add Owner

Add lens owner.

Command LinePython

./araalictl api -update-lens-owner -email=<email> -zone=<zone> -app=<app> -owner-op=add
./araalictl api -update-lens-owner -email=<email> -service=<ip|dns>:<port> -owner-op=add

Del Owner

Add lens owner.

Command LinePython

./araalictl api -update-lens-owner -email=<email> -zone=<zone> -app=<app> -owner-op=del
./araalictl api -update-lens-owner -email=<email> -service=<ip|dns>:<port> -owner-op=del

Slack

Our Slack is the main discussion space for the Araali Networks community.

Join our slack.

Video

Watch our videos.

• 3-minute Intro video

• 20-minute Demo video

• 1-minute Running Assessment video

Blog

Read our blog.

• Motivation

• End of traditional appsec

• Eliminate risk of stolen passwords

• Distributed Zero Trust

• Complete Zero Trust Guide

Contributing

This documentation is currently open-source, meaning you can submit pull requests on the GitHub page to change the documentation.

Installation/Setup

Clone Repo

1. Login into GitHub (or create your account)

2. Setup ssh (upload your public key to github account)

3. Fork the existing repo (top-right button)

4. Clone the forked repo using ssh (not html)

   • Click the clone button to get repo details for ssh

5. git clone <repo link from step 4>

6. Make changes (see How to Use rST Files)

7. Push changes

8. Submit pull request

9. Keep fork synced to upstream by following the steps for UI on this link, then executing the following lines to get the synced-up changes on your laptop:

   git pull -r
   # this line might fail
   # in that case, stash and pop your local changes
   # to make sure the pull goes through
   git stash
   git pull -r
   git stash pop
   

Install sphinx-doc using your system installer

mac install:

brew install sphinx-doc

linux install:

sudo apt-get -y install sphinx-doc

Make sure sphinx-build is in your path

Let the installer prompt you for the path. Or see manual instructions below.

cd api/doc
sudo find / -name sphinx-build -print 2>/dev/null
export PATH=$PATH:<new_path_where_sphinx-build_is>

new_path_where_sphinx-build_is is where you have above sphinx-build

Eg: PATH="/usr/local/opt/sphinx-doc/bin:$PATH

cat ~/.zshrc

You can put this in your .bashrc or .zshrc so it is automatically set on next login/terminal

source ~/.bashrc

Set up Sphinx with Python

Follow this link

python3 -m venv ve-name
# even when you open a new terminal next time, this is how
# you get into the virtual environment
source ve-name/bin/activate
# now all this goes into your virtual env - which is very isolated
# and predictable environment to be in
# next time there is no need to install these. Just entering your
# virtual env gets you all the packages.
pip install sphinx
pip install sphinx_rtd_theme

Repeat these steps to see changes in action

make clean html

To run locally:
    open build/html/index.html

To run remotely:
    python -m http.server 8000
    In a browser, <ip_of_your_server>:8000

How to Use rST Files

To contribute to the documentation, some knowledge of rST is required. Below are some helpful links.

• Docutils or reStructuredText

• A reStructuredText Primer

• Documenting Your Project Using Sphinx — an_example_pypi_project v0.0.5 documentation

• reStructuredText Primer - Sphinx Documentation

• Sphinx Tutorial

• Sphinx Cheat Sheet

• Online reStructuredText Editor