...
<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>
Edge Node Deployment (Day 1)
On the target edge node, native (non-containerized) anax and KubeArmor agents
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.
KubeArmor agent installation
Instead of altering the "agent-install.sh" script to trigger the KubeArmor installation process, we are proposing that a completely separate script be created that will install a native KubeArmor application, and then signal to anax that it has been installed and is ready to use. This assumes that anax has already been installed and configured, but does not need to be registered with an exchange for KubeArmor to be installed. In fact, if we are proposing to create or modify the node policy file, it is better if the anax agent is not currently registered.
On the target cluster
Remote, zero-touch provisioning (FDO)
Deployment UX
- Should we consider k8s mode of deployment or pure-containerized mode of deployment? KubeArmor works best with k8s mode of deployment and is the recommended mode. Having said that, the previous integration/demo/POC done with OH was in pure-containerized mode.
- How would the deployment of KubeArmor on the target edge node happen? Will it be deployed as a separate workload with its own control plane or will it be integrated into the same control plane as that of OH?
- There is a value in keeping KubeArmor and associated tooling decoupled from Anax and OH Management Hub. This would allow independent updates and essentially the security should be considered as one more addon from the service provider side of things.
- The real challenge here is how would OH framework allow extensions to be built to integrate third party tooling?
- Ship the hardening policies along with the KubeArmor installation.
...