Page History

...

On the target edge node, native (non-containerized) anax and KubeArmor agents

Working assumptions

• We are setting a precedent for installation of optional third-party components
• To simplify the installation process, keep each operation atomic, and to allow components to be installed in any order, all component installations will be decoupled from the base anax installation.
• The process should also function if a person is "bringing their own already-installed component" and we are just integrating anax with a pre-existing KubeArmor installation.
• The default case will be based on native applications, not containerized versions, although both options or a mix thereof should work.
• The integration should also be easily reversible.
• Workload deployment policies may optionally support this integration by specifying a security policy to deploy and activate along with the workload.
• Node policies can specify a default security policy to apply to one or more workloads running on that node.
• Deployment policies can override the node's default security policy due to greater specificity.
• A node may have more than one anax agent running, but anax > 1 must always be containerized.
• The same should apply to the KubeArmor agent ... agents>= 2 must be containerized and should not protect the host.

anax agent installation

Today, installing the agent on the target device involves running the "agent-install.sh" script as documented at Automated agent installation and registration.  At this point, we are assuming that no signal needs to be sent to this installation script and process to notify it that KubeArmor should also be installed.  If that were the case, we should consider a flag in the form of an installation argument or an environment variable.  This will allow us to decouple the process of installing KubeArmor as an optional security component.

...