enterpriseconnect/qa repository overview

⁠EC OCI Spec

It is recommneded running the containers specified in this repo in rootless mode for better security.

Cgroup resided in docker core which by design requires a sudoer permission from the guest system. Docker users who wish to level up the security by running a non-sudoer user inside the container should avoid the volume-sharing on the guest host.

Because of this, it is highly recommended to running this image as a rootless/unpriviliged container. Please refer to runc⁠ and linux cgroup man man cgroups⁠ for further study.

The open-source projects adoption flow- cgroup >> runc + nsenter >> moby >> docker

The root permission per se defeats the purpose of EC rootless-connectivity model and ultimately create several security leaks on the guest host. However, it is worth to note that running a standalone agent does NOT require a sudoer/root permission. Please refer to the agent source code repo for the standalone deployment⁠. Users with restrict security environemnt one such as AWS GovCloud should consider using a self-build image based on the spec examples in this repo.

The EC Agent OCI image is currently maintained on public docker hub⁠; the usage spec avaialble in several compute environments. Visit the EC usage examples⁠ or the wiki if new to EC⁠.

OCI (Open Container Initiative) is a contionue trademark of the Open Container Initiative Community⁠ and currently governed by the community charters⁠

⁠Docker Tags

⁠build agent-related artifacts

⁠pull example

docker pull enterpriseconnect/build:v1beta

⁠available tags

• v1⁠, latest
• v1beta⁠
• v1.1beta⁠

⁠tag usage

• v1 refers to the image to build agent #212+-relate releases.
• v1beta refers to the image to build agent #1724+-relate releases.
• v1.1beta refers to the image to build agent #2721+-relate releases.

⁠agent in containers

⁠pull example

docker pull enterpriseconnect/agent:v1beta

⁠avaialble tags

• v1⁠, latest⁠, v1-slim⁠
• v1-python, v1-ci
• v1beta⁠, v1beta-slim⁠
• v1beta-python, v1beta-ci
• v1beta-build⁠
• v1-build⁠

⁠Tag usage

• v1 refers to agent #212 release.
• v1beta include agent #1724 candidate release.
• <tag>-build include the series of tool to build out an agent release.

⁠How to run

In this container spec example, the pre-defined agent image is launched by using docker. The agent flags in this example are converted into several environment variables that are required based on the <path/to/this/repo>/spec/<agent-mode>.yml for a EC usage. For instance, to launch a client-mode agent container, it is required to ingest env vars EC_AID, EC_TID, EC_HST, etc.

The env variables specified in --env-file will need to be replaced by a series of relevant flags as it is shown in the example yaml file.

docker run -v $(pwd)/<the local agent config yam file. e.g. client.yml>:/build/conf.yml \
enterpriseconnect/agent:v1.1beta

⁠How to Run (Azure)

placeholder. Issue tracking⁠

⁠Kubernates Deployment example

When deploy the agent in a k8s instance, the necessary environment variables as specified in the example /path/to/the/repo/k8s/agent-<object>.yml. k8s users may utilise any custom objects such as a configmap plugin to help in its configuration.