Improving the logic of kubesec advise

[Quanalogy]

Hi,

I stumbled over your tool reading up to CKS and I find it quite useful and I'm considering if it could be useful to integrate into my workflow at work. However to make this tool useful I find that a few features seems to be missing and some logic to be, in my opinion, lacking.

Here are my two cents.

Advise improvements

In this section I'll base my statements of scanning a yaml manifest created on a kubernetes v1.32.1 which can be recreated with kubectl create deployment nginx --image nginx --dry-run=client -o yaml and scanning it with docker run -i kubesec/kubesec:v2 scan /dev/stdin < training/trash/nginx.deploy.yaml

the advise (jq '.[].scoring.advise') have the following statements which I have issues with:

1. Seccomp rule SeccompAny specify using seccomp using annotations. This have not been like that since 1.19 and should instead be specified under spec.template.spec.securityContext.seccompProfile
2. Default ServiceAccountName rule makes little sense to me however let's just consider that people might be generally granting the default SA permissions, then it makes no sense that this rule is still failing when setting spec.template.spec.automountServiceAccountToken: false
3. AppArmor rule ApparmorAny is also specified as a annotation, however this is also moved, namely to spec.template.spec.securityContext.appArmorProfile
4. There is no rule for using SELinux - which also should be something that is either/or with apparmor profile

Improvements to make CI make sense

So looking into making this a tools I would use in CI I think the following things would be required:

1. Ability to exclude rules
   • I think we can all agree that some rules are fundamental, while others is both system specific and up for debate if it is actually required in a given context. AppArmor and SELinux come to mind.
2. Ability to fail when the advise section contains elements
3. Ability to set score required to pass.

I hope you find these suggestions useful :)