Each pod should declare it's securityContext

[kristinochka]

Is your enhancement related to a problem? Please describe.

For best security practices, the securityContext under each Pod must be fully declared in order to clearly communicate the workload's security posture. In order to be declarative about their security posture, Pods must define every parameter available in its securityContext and each container's securityContext.

Describe the solution you'd like

The following deployment don't have security definitions:
deploy/operator-local.yaml
deploy/operator.yaml

For example:

kind: Pod
spec:
  containers:
  - securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      runAsUser: 1001
  hostIPC: false
  hostNetwork: false
  hostPID: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001

Describe alternatives you've considered

Additional context

[kristinochka]

Little bit more clarification:
Pods must define every parameter available in its securityContext and each container's securityContext. For Pods, this includes hostNetwork, hostPID, and hostIPC. For each container, this includes privileged, readOnlyRootFilesystem, allowPrivilegeEscalation, and at least one element in capabilities.add or capabilities.drop. The runAsNonRoot and runAsUser parameters may be defined on each container individually or on the Pod to apply it to all containers. If either is not defined on a container, then it must be defined on the Pod. In the context of an OpenShift cluster, runAsUser is not required. Some parameters have specific requirements regarding the acceptable values, but it is most important that each is defined in order to be declarative about the product's security posture.

[ArvinB]

This is resolved with the latest PR I contributed:
eclipse-che/che-operator#811

We can close this one out.