Trouble with K8s platform expecting Jobs to meet security requirements

[aicardi-obspm]

I tested lithops with a Rancher installation by e-INFRA CZ for the EGI federation.

I don't know if all Rancher installations are the same, but this one expects containers to meet some security requirements, such as non root execution and no privilege escalation.

I managed to create K8s jobs with lithops ont this platform after modifying the JOB_DEFAULT variable in lithops/serverles/backends/k8s/config.py with the lines :

      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        runAsUser: 1000
        capabilities:
          drop: ["ALL"]
        seccompProfile:
          type: "RuntimeDefault"

I guess that this workaround is not the right way to configure lithops with kubernetes, so I don't propose this as a pull request.

[JosepSampe]

Hi @aicardi-obspm — thanks a lot for sharing this! I haven’t tested Lithops on Rancher either, so I’m not sure if other Rancher setups would require the same security constraints, but it definitely makes sense to document and support this kind of scenario.

A good way to move forward might be to introduce a new k8s_platform config parameter (e.g., with values like default or rancher), and then define a separate JOB_DEFAULT_RANCHER configuration including your securityContext settings. We could then load either JOB_DEFAULT or JOB_DEFAULT_RANCHER based on the value of k8s_platform in:
https://github.com/lithops-cloud/lithops/blob/master/lithops/serverless/backends/k8s/k8s.py#L454
https://github.com/lithops-cloud/lithops/blob/master/lithops/serverless/backends/k8s/k8s.py#L642
https://github.com/lithops-cloud/lithops/blob/master/lithops/serverless/backends/k8s/k8s.py#L691

Would you be interested in drafting a PR for this? Otherwise, I can help put it together based on your notes. Either way, I agree it would be valuable to upstream this.

[mskuratowski]

PR up: #1463.

@JosepSampe Made it generic (pod_security_context / container_security_context raw dicts) instead of k8s_platform: rancher because same problem hits OpenShift, GKE Autopilot, EKS with admission, etc., so a vendor-named enum would grow. Container-level defaults to PSS Baseline; pod-level stays opt-in.

Non-root runtime image as a separate follow-up PR.

@aicardi-obspm does the PSS Restricted snippet in the new docs section match what your cluster expects?