Using noah in a container

Use the noah container image in your environment.

This step-by-step procedure will guide you on how to use the noah agent image. In the picture above, the noah agent are the small NearEDGE logo inside containers that are represented by the Kubernetes icon.

The noah solution enables devOps team member to have access to TCP servers in remote assets. It acts as a classic TCP port forwarder and was developed to easily integrate into any environment. Its zero-touch deployment is CI/CD friendly.

The port forwarding is always using 127.0.0.1 as the target IP address. As such, noah is restricted in accessing local servers at the remote asset.

The NearEDGE noah agent image is flexible and allows various deployment configuration. In this guide we will cover the following use cases:

• Standalone container with host networking - Use this method to unlocks access to the host's TCP servers.
• As a side-car or in a pod - As a side-car, the noah agent may enable interacting with processes of the associated container. It can also be used to reach the TCP servers of a the container using its loopback interface.
• Inside a custom container - When operating from within a custom container, the noah agent is used to reach the TCP servers of a specific container using its loopback interface.

The noah agent connects to the Access Gateway. Installing and running a gateway is covered by 2 step-by-step guides. One of the guide covers using it in a virtual machine environment, while the other covers the container variant.

The noah container image

NearEDGE provides a noah agent image that was built using a basic alpine image. This base image provides a basic toolset and the MUSL C library. With this image, you can run busybox to inspect files, list processes and do other such small tasks. See the official alpine repository.

The final image is augmented with some fully static binaries. Theses binaries may be extracted and use elsewhere since they do not have any dependency on external libraries of any sort. Here is a list of what was added

• tcpdump - Everybody knows tcpdump, right? It is a tool that captures packets on an interface.
• sshd - openSSH server daemon.
• chainstart - A helper program that can starts multiple children processes. You can use it or anything else that suits your needs.
• noah - The noah agent.

The ENTRYPOINT is only configured to start the noah agent. You could, if required, override it with your own command.

The noah image is specific to your organization. In this guide, we will simply refer to it with <image>. You can get a summary of first steps from the container image by running:

docker run <image> --firststeps

This guide wont't cover the use of SSH nor how to enable it. For a discussion about SSH and noah see this guide

Using noah to access host servers

Remote access to server(s) listening on the host loopback interface is made easy with noah. Running the noah agent can be as simple as downloading your organization's version of the noah agent from the NearEDGE dashboard, or extracting it from the image and starting it anyway you like.

Alternatively, you can simply use the noah container without modification by attaching it to the host network. Simply use the following command:

docker run --volume <uniquename>:/noah --restart always --detach --net host --name noah <image>

<uniquename> is a named volume, or a file system path, providing persistence. The noah agent uses it to store information across restart and that are unique to a container instance.

Using noah to access servers in a running container

Another use case for the noah image is to run it as a side-car in a pod (in a kubernetes environment) or associated to a main docker container instance. We are not covering the pod case here but will cover the docker use case. Associating a container with another one is analogous to the runtime scenario of a pod where

• Both containers share the same network interfaces, particularly the loopback interface.
• The process space can also be shared.
• Mounted volume(s) can be shared.

The following command will start the noah image as an associated container:

docker run  --volume <uniquename>:/noah --volumes-from <container name> --restart always --detach --net container:<container name> --name noah <image>

<container name> is the main container instance name.

--volumes-from <container name> may be omitted if access to mounted volume is unnecessary.

Use --pid container:<container name> (not on the command line above) to attach to the main container process space.

As is the case when connecting to the host network, the <uniquename> is a named volume, or a file system path, providing persistence. The noah agent uses it to store information across restart and that are unique to a container instance.

This mode of operation is useful for accessing server(s) attached by the main container on the loopback interface. You could also enable an SSH server on the noah container (see this guide) and use the tools provided by the alpine base image.

Using noah from inside a container instance

Another method of using noah is to run it directly inside your container. You do this simply by adding the noah agent software and starting it. The main benefits of using this method are:

• Easier integration by using the CI/CD pipeline instead of modifying the container environment.
• No extra running container added to the service stack.
• Access to all resources in the main container, including the root filesystem. Through SSH, you can then execute tools provided by your image.

The process is simple, all you need to do is to reference your noah image and pull the noah agent. Here is a complete example (taken from the debugging python howto).

#
# Get the noah agent
#
# Use the repository specific to YOUR organization - Below is
# just an example
FROM <image> as noah

#
# Test project (final container image)
#
# Use whatever base image suitable for your application.
FROM python:latest

RUN pip3 install flask debugpy

# Remote access is provided by noah
RUN mkdir /noah
COPY --from=noah /opt/ne/chainstart /opt/chainstart
COPY --from=noah /opt/ne/noah /opt/noah

# Actual application
COPY app.py /opt/demo/

#
# Start noah and the demo python code - Using chainstart
#
ENTRYPOINT ["/opt/chainstart", \
  "--", "/opt/noah", "--dataloc", "/noah", \
  "--", "/usr/local/bin/python3", "-m", "debugpy", \
      "--listen", "127.0.0.1:12345", "--wait-for-client", \
      "/opt/demo/app.py"]

We use chainstart to start both the noah agent as well as the application. You can use other means, such as a bash script, as you see fit. Make sure to start noah with the correct argument(s).

As with the 2 other cases above, you should start the container by providing a volume for the /noah internal path. It could be a named volume, or a file system path. The noah agent uses it to store information across restart and that are unique to a container instance.

Additional resources

To complement this step-by-step procedure, you may find the following guides useful.

• Deploying an Access Gateways in a virtual machine
• Deploying an Access Gateways as a container
• Start the included SSH daemon
• Include SSH in your custom container image