#146 Fixing Container Security Context Logic #149
Conversation
Kubernetes rationalizes Container Security Context in conjuction with the Pod Spec Security Context. In this scenario you can 'leave out' certain security context settings and rely on the pod spec definition to still set these settings for you. The RunAsNonRoot setting originally only checked to see if the value was set at the container level, vs also checking if it was enabled at the pod level. I have attached the container's parent pod spec to the container validate struct in case any other things like this arise in the future. I have also refactored the logic for validating bool pointers, since these can be tricky, if you want to avoid dereferences pointer issues. Changes: - Added parent pod spec of container to validate certain settings which affect container spec - Refactored the logic statements for validating bool pointers (used helpers) - Added tests for this pod.container.securityContext condition
|
I'm interested if anyone has any other ideas on how to solve this issue of podSpec affecting unset values in containers. Another potential way to go about this is to check each container (while in the pod validation) if the security-context is set to |
Had to adjust the logic to test more conditions than just if _either_ one was true. A condition came up where PodSpec was True and Container was explicitly False (which caused a false positive good grade).
|
FYI I'm still missing the CHANGELOG additions (when this eventually is ready) |
|
This is awesome, thanks for chasing it down! Tests look solid. I looked a bit at SecurityContext vs PodSecurityContext, and this seems to be the only variable that's shared between the two. Re: changelog, I've just been updating at release time (since we don't know the eventual version number). You're welcome to start an "In Progress" section though. Other than the comment on bool helpers this LGTM. |
Was missing a test case where podspec was set as a good value but the container spec is explicitly a bad setting. The previous code would return a 'good' rating, which would be incorrect.
Kubernetes rationalizes Container Security Context in conjuction with the
Pod Spec Security Context. In this scenario you can 'leave out' certain
security context settings and rely on the pod spec definition to still
set these settings for you. The RunAsNonRoot setting originally only checked
to see if the value was set at the container level, vs also checking if it
was enabled at the pod level.
I have attached the container's parent pod spec to the container validate
struct in case any other things like this arise in the future.
I have also refactored the logic for validating bool pointers, since these
can be tricky, if you want to avoid dereferences pointer issues.
Changes: