Question: PodSecurity policy check with uid >= 10000 ok?

[markuslackner]

Many helm charts/docker containers use uid 1000 by default. Also in the kubernetes docs there is a sample with uid 1000 (https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). In our environment it would be quite an effort to switch to uids > 10000. On the other hand i dont want to skip this check.

My question : Is enforcing uid >= 10000 necessary and an security improvement or would it be sufficient to enforce uid >= 1000? Would it be a reasonable feature request to enhance kube-score to allow configuring which uid/gid to check?

[zegl]

A common pattern is to use uid < 10000 for host local uids, and uids >= 10000 for "remote users". I still think that it makes sense to recommend higher uids, to avoid collitions.

[markuslackner]

ok, i see your point. My problem is the "practical" aspect when using docker images from e.g. dockerhub. Often they are using 1000 or 1001 by default and you have to extend them to use another uid/gid. Also most of the guides i have seen for writing security policies in for example helm charts use uid 1001. So i am thinking if kube-score should check for uid >= 1000 because it is widely used in practice although 10000 is correct from a technical point of view.

[mgier]

Would appreciate this, too. If not as default, maybe with an additional config-flag? Something like "strict UID check"?

[zegl]

Would appreciate this, too. If not as default, maybe with an additional config-flag? Something like "strict UID check"?

If you want to disable this test, you can do so with the --ignore-test or kube-score/ignore annotation.

[mgier]

Hi @zegl ,

thanks for the fast reply. We checked this option already, but then we have to disable all checks from container-security-context?

We would like to keep the other checks. Right now, the UID check pops up for almost all of our deployments, which makes it hard to use kube-score for us at all because almost every deployment is marked as critical.

[zegl]

We would like to keep the other checks.

Fair enough, I think that it would make sense to split this check into multiple smaller ones, that can be enabled/disabled individually. I've opened #325 to track this implementation.