Getting Started

Assuming that you installed the operator in the starboard-operator namespace, and it's configured to discover Kubernetes workloads in the default namespace, let's create the nginx Deployment that we know is vulnerable:

kubectl create deployment nginx --image nginx:1.16

When the first pod controlled by the nginx Deployment is started, the operator immediately detects that and creates the Kubernetes job in the starboard-operator namespace to scan the nginx container's image (nginx:1.16) for vulnerabilities. It also creates another job to audit the pod's template for common configuration pitfalls such as running the nginx container as root:

$ kubectl get job -n starboard-operator
NAME                                 COMPLETIONS   DURATION   AGE
scan-configauditreport-c4956cb9d     0/1           1s         1s
scan-vulnerabilityreport-c4956cb9d   0/1           1s         1s

If everything goes fine, the scan jobs are deleted, and the operator saves scan reports as custom resources in the default namespace, named after the Deployment's active ReplicaSet. For image vulnerability scans, the operator creates a report for each different container defined in the active ReplicaSet. In this example there is just one container image called nginx:

$ kubectl get vulnerabilityreports -o wide
NAME                                REPOSITORY      TAG    SCANNER   AGE     CRITICAL   HIGH   MEDIUM   LOW   UNKNOWN
replicaset-nginx-7ff78f74b9-nginx   library/nginx   1.16   Trivy     9m57s   1          33     22       86    0

Similarly, the operator creates a configauditreport resource holding the result of auditing the configuration of the active ReplicaSet controlled by the nginx Deployment:

$ kubectl get configauditreports -o wide
NAME                          SCANNER   PASS   DANGER   WARNING
replicaset-nginx-7ff78f74b9   Polaris   9      0        8

Notice that scan reports generated by the operator are owned by corresponding Kubernetes workloads. In our example, vulnerabilityreports and configauditreports objects are owned by the active ReplicaSet of the nginx Deployment:

$ kubectl tree deploy nginx
NAMESPACE  NAME                                                       READY  REASON  AGE
default    Deployment/nginx                                           -              44m
default    └─ReplicaSet/nginx-7ff78f74b9                              -              44m
default      ├─ConfigAuditReport/replicaset-nginx-7ff78f74b9          -              44m
default      ├─Pod/nginx-7ff78f74b9-l6w8p                             True           44m
default      └─VulnerabilityReport/replicaset-nginx-7ff78f74b9-nginx  -              43m

Note

The tree command is a kubectl plugin to browse Kubernetes object hierarchies as a tree.

Tip

You can get and describe vulnerabilityreports and configauditreports as built-in Kubernetes objects:

kubectl get vulnerabilityreports replicaset-nginx-7ff78f74b9-nginx -o json
kubectl describe configauditreports replicaset-nginx-7ff78f74b9