modify container security context

[marekzebro]

SUMMARY

Changes for adding/modifying securityContext of a container. It re-uses already present variable security_context_settings. All security context items can be added as key-value pair under a name of each container.

ISSUE TYPE

• New or Enhanced Feature #1413

ADDITIONAL INFORMATION

[marekzebro]

Is this change acceptable?

[rooftopcellist]

@marekzebro Thank you for your contribution! Yes, this is a welcome change, sorry for the wait, I was OOO, back now.

Could you rebase this PR? I left one comment on the readme section. This is also missing an entry in the CSV for the Openshift form descriptors. Something like this here should be sufficient:

      - displayName: Custom Security Context
        path: security_context_settings
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:advanced

[rchaud]

@marekzebro @rooftopcellist @fosterseth Is there an ETA on this?

[rooftopcellist]

@marekzebro This is a good change, and it is well orchestrated. However, we intend to restructure our CRD schema to follow a format more like the following for deployment specific settings like this:

---
spec:
  web:
    init:
      security_context_settings:
        capabilities:
          add:
            - CHOWN
            - SETUID
            - SETGID
        runAsUser: 1000
        runAsGroup: 1000
    web:
      security_context_settings:
        capabilities:
          add:
            - CHOWN
            - SETUID
            - SETGID
        runAsUser: 1000
        runAsGroup: 1000

Notice that the setting are nested under the deployment name (web in this context), then the container inside that deployment (for example init). Then the variables would be referenced in the templates as web.init.security_context_settings, for example.

I don't think we want to merge this in it's current state because users would start using it in their AWX specs, then when we ultimately refactor, those users would have functionality be broken (their security context settings would not be applied on the deployments as the key ref wouldn't be evaluated).

Here is an example of what type of nested deployment options we would like to get to:

• https://github.com/ansible/eda-server-operator/blob/main/config/crd/bases/eda.ansible.com_edas.yaml#L88-L114

This PR might be a good place to start. @marekzebro feel free to reach out in Matrix if you want help with this.

[rooftopcellist]

For now, let's move forward with adding the security context param per deployment in this format:

• web_security_context
• task_security_context
• etc.

This way, all of v1beta1 will use the same web_<setting> format.

Then, when we do a v2 awx apiVersion down the line, we can adopt the new schema I described in the earlier comment.