--gRPC string gRPC server information
--help help for log
--json Flag to print alerts and logs in the JSON format
--logFilter string What kinds of alerts and logs to receive, {policy|system|all} (default "policy")
--logPath string Output location for alerts and logs, {path|stdout|none} (default "stdout")
--msgPath string Output location for messages, {path|stdout|none} (default "none")
Note that you will see alerts and logs generated right after karmor runs logs; thus, we recommend to run the above command in other terminal to see logs live.
2. Test KubeArmor using the auto-testing framework
2.1. Prepare microservices and test scenarios
The auto-testing framework operates based on two things: microservices and test scenarios for each microservice.
Microservices
Create a directory for a microservice in microservices
$ cd KubeArmor/tests/microservices
~/KubeArmor/tests/microservices$ mkdir [microservice name]
Then, create YAML files for the microservice
$ cd KubeArmor/tests/microservices/[microservice name]
~/KubeArmor/tests/microservices/[microservice name]$ ...
As an example, we created 'multiubuntu' in microservices and defined 'multiubuntu-deployment.yaml' in multiubuntu.
Test scenarios
Create a directory whose name is like '[microservice name]_[scenario name]' in scenarios
$ cd KubeArmor/tests/scenarios
~/KubeArmor/tests/scenarios$ mkdir [microservice name]_[scenario name]
Then, define a YAML file for a test policy in the directory
~/KubeArmor/tests/scenarios$ cd [microservice name]_[scenario name]
.../[microservice name]_[scenario name]$ vi [policy name].yaml
Create cmd files whose names are like 'cmd#'
.../[microservice name]_[scenario name]$ vi cmd1 / cmd2 / ...
Here is a template for a cmd file.
source: [pod name]
cmd: [command to trigger a policy violation]
result: [expected result], { passed | failed }
---
operation: [operation], { Process | File | Network }
condition: [matching string]
action: [action in a policy] { Allow | Audit | Block }