Control Telemetry/Visibility
KubeArmor currently supports enabling visibility for containers and hosts.
Visibility for hosts is not enabled by default, however it is enabled by default for containers .
The karmor
tool provides access to both using karmor logs
.
Prerequisites
If you don't have access to a K8s cluster, please follow this to set one up.
karmor CLI tool: Download and install karmor-cli
Example: wordpress-mysql
To deploy wordpress-mysql app follow this
Now we need to deploy some sample policies
kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/examples/wordpress-mysql/security-policies/ksp-wordpress-block-process.yaml
This sample policy blocks execution of the apt
and apt-get
commands in wordpress pods with label selector app: wordpress
.
Getting Container Visibility
Checking default visibility
Container visibility is enabled by default. We can check it using
kubectl describe
and grepkubearmor-visibility
POD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl describe -n wordpress-mysql pod $POD_NAME | grep kubearmor-visibility kubearmor-visibility: process, file, network, capabilities
For pre-existing workloads : Enable visibility using
kubectl annotate
. Currently KubeArmor supportsprocess
,file
,network
,capabilities
kubectl annotate pods <pod-name> -n wordpress-mysql "kubearmor-visibility=process,file,network,capabilities"
Open up a terminal, and watch logs using the
karmor
clikarmor logs
In another terminal, simulate a policy violation . Try
sleep
inside a podPOD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl -n wordpress-mysql exec -it $POD_NAME -- bash # apt update
In the terminal running
karmor logs
, the policy violation along with container visibility is shown, in this case for exampleThe logs can also be generated in JSON format using
karmor logs --json
Getting Host Visibility
Host Visibility is not enabled by default . To enable Host Visibility we need to annotate the node using
kubectl annotate node
kubectl annotate node <node-name> "kubearmor-visibility=process,file,network,capabilities"
To confirm it use
kubectl describe
and grepkubearmor-visibility
kubectl describe node <node-name> | grep kubearmor-visibility
Now we can get general telemetry events in the context of the host using
karmor logs
.The logs related to Host Visibility will have typeType: HostLog
andOperation: File | Process | Network
karmor logs --logFilter=all
Updating Namespace Visibility
KubeArmor has the ability to let the user select what kind of events have to be traced by changing the annotation kubearmor-visibility
at the namespace.
Checking Namespace visibility
Namespace visibility can be checked using
kubectl describe
.
kubectl describe ns wordpress-mysql | grep kubearmor-visibility kubearmor-visibility: process, file, network, capabilities
To update the visibility of namespace : Now let's update Kubearmor visibility using
kubectl annotate
. Currently KubeArmor supportsprocess
,file
,network
,capabilities
. Lets try to update visibility for the namespacewordpress-mysql
kubectl annotate ns wordpress-mysql kubearmor-visibility=network --overwrite "namespace/wordpress-mysql annotated"
Note: To turn off the visibility across all aspects, use
kubearmor-visibility=none
. Note that any policy violations or events that results in non-success returns would still be reported in the logs.Open up a terminal, and watch logs using the
karmor
clikarmor logs --logFilter=all -n wordpress-mysql
In another terminal, let's exec into the pod and run some process commands . Try
ls
inside the podPOD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl -n wordpress-mysql exec -it $POD_NAME -- bash # ls
Now, we can notice that no logs have been generated for the above command and logs with only
Operation: Network
are shown.Note If telemetry is disabled, the user wont get audit event even if there is an audit rule.
Note Only the logs are affected by changing the visibility, we still get all the alerts that are generated.
Let's simulate a sample policy violation, and see whether we still get alerts or not.
Policy violation :
POD_NAME=$(kubectl get pods -n wordpress-mysql -l app=wordpress -o jsonpath='{.items[0].metadata.name}') && kubectl -n wordpress-mysql exec -it $POD_NAME -- bash #apt
Here, note that the alert with
Operation: Process
is reported.
Last updated
Was this helpful?