Release ARM64 agent version

[3asm]

Users on Mac with M1 require ARM64 images. We currently only support and release x64 images which require a compatibility runtime.

Adding this requires multi-dockerfile support and agent builders supporting ARM64.

[Cyb3rDudu]

I currently do not understand the DevOps you are using to build the images but maybe I can help.

As you use the build-push-action which uses buildx, multi platform builds could be made by this action if setup like bellow.

        ...
        name: Set up QEMU
        uses: docker/setup-qemu-action@v2
      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2
      -
        name: Build and push
        uses: docker/build-push-action@v3
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: user/app:latest
         ...

However, I see that the GitHub actions workflows for the docker build, in the agent repositories are all commented. So I'm not sure how the builds are made. Regarding the Dockerfile we might be able to build all architectures from one file.

How are the image builds currently implemented?

[3asm]

Thanks, @jamu85 this is very helpful.

[Cyb3rDudu]

@3asm I have a POC building a multi arch image and pushes the docker container to docker hub. https://github.com/jamu85/agent_nmap/runs/7559368257?check_suite_focus=true and here the result https://hub.docker.com/repository/docker/jamu85/agent_nmap

We can tweak versioning etc to the needs but basically, we can easily roll out mulltiarch images to the ostorlab registry by this GitHub action.

[Cyb3rDudu]

@3asm Can I help with that? I believe i just need you to set 3 secrets for the GitHub action to access the registry and explain me how the images need to be tagged. The secrets are DOCKER_USER, DOCKER_PASSWORD and DOCKER_REGISTRY. With them, I could add GH actions that can push arm and x86 container builds into your store registry. I would love to get ostorlab running on my mac so that I can focus on a couple of agents I need.

[3asm]

This is awesome @jamu85 .

The building is an important piece, but would probably be only a small piece. Here are the actions I see to add support for architecture support:

• Ostorlab uses an agent to build agents (it's meta :). The agent uses the docker build command used locally to build agents. This is done as we experienced discrepancies between tools like Kaniko and docker build. The first step consists of adding support of multiarch build to the agent. It is not using buildx as the API does not expose it, so switching to buildx need to be done in local cli as well to avoid discrepancies.
• The second piece is the dockerfile. I believe there are cases where we would need different dockerfile for different architectures. To safely support that, we need to add an extra field to the agent definition YAML file pointing to the matching architecture. Something like dockerfile_arm64 or dockerfile,arm64 or turn the dockerfile into a key value type.
• Once these are resolved, comes the agent install phase which needs to check if the agents / docker image supports the system architecture and fetches correctly.
• Part of the building work is indicating on the store what architectures are supported, which means changes to the store model to add architecture reference, adding it to the API, and making sure the build agent populates it correctly.
• Once the build and run steps are covered, the final actions would be adding multi-arch support to the agent template to make it easier to add support for agent builders and then going over all the agents to add support for the new architectures.
• The final step would be changing the github actions workflow to add support for running testing on multiple architectures