various securityContext-related fixes

[cjvirtucio87]

My cluster enables the Pod Security admission controller, which requires every pod to adhere to pod security standards:

W1201 09:34:55.535139   14754 warnings.go:70] would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "stunner-auth-server" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "stunner-auth-server" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "stunner-auth-server" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "stunner-auth-server" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

This PR allows chart consumers to set the securityContext of some resources to values that adhere to those standards. The original values are kept as defaults.

[davidkornel]

Hi there, thank you for your participation. I left some comments for the auth-service changes.

Unfortunately, the extra field added for the dataplane object is not supported. I am not familiar with the containerSecurityContext field. Isn't the securityContext field enough for your use case? Also, please take a look at what field are supported in the dataplane spec

[davidkornel]

Please, see the one comment

[cjvirtucio87]

Hi there, thank you for your participation. I left some comments for the auth-service changes.

Unfortunately, the extra field added for the dataplane object is not supported. I am not familiar with the containerSecurityContext field. Isn't the securityContext field enough for your use case? Also, please take a look at what field are supported in the dataplane spec

when the gateway operator detects a change to the dataplane's spec, it iterates through the expected containers and sets the securityContext for each container, using the value of containerSecurityContext from the dataplane spec.

securityContext on the dataplane spec only configures the pod-level securityContext:

% kubectl explain deployment.spec.template.spec.securityContext

...
    SecurityContext holds pod-level security attributes and common container
    settings. Optional: Defaults to empty.  See type description for default
    values of each field.
    PodSecurityContext holds pod-level security attributes and common container
    settings. Some fields are also present in container.securityContext.  Field
    values of container.securityContext take precedence over field values of
    PodSecurityContext.

as opposed to the securityContext for the container:

% kubectl explain deployment.spec.template.spec.containers.securityContext

...

    SecurityContext defines the security options the container should be run
    with. If set, the fields of SecurityContext override the equivalent fields
    of PodSecurityContext. More info:
    https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
    SecurityContext holds security configuration that will be applied to a
    container. Some fields are present in both SecurityContext and
    PodSecurityContext.  When both are set, the values in SecurityContext take
    precedence.

it's not stated in the standards why the container-level securityContext needs to be restricted as opposed to the pod, but I'm guessing it's because it completely avoids the risk of the container one overriding the pod's.

[davidkornel]

LGTM, thanks.