Add custom settings for podSecurityContext and containerSecurityContext instead of global securityContext

[mustaphaaa]

Summary

This pull request introduces custom settings for podSecurityContext and containerSecurityContext to ensure compatibility with restricted Pod Security Admission levels. By adjusting the security context configurationsat the pod and the container level, the application will adhere to the stricter security policies enforced within the Kubernetes cluster.

Context

Currently, the application is unable to run in Kubernetes environments with restricted Pod Security Admission levels due to insufficient security context configurations. This pull request addresses this issue by implementing the necessary adjustments to the security settings, thereby enabling the application to be deployed and run securely in such environments.

When deploying imgproxy in a namespace with pod-security.kubernetes.io/enforce: baseline and we set the values like this :

securityContext: runAsNonRoot: true allowPrivilegeEscalation: false capabilities: drop: - ALL seccompProfile: type: RuntimeDefault

We get this warning :

Warning: would violate PodSecurity "restricted:v1.27": allowPrivilegeEscalation != false (container "imgproxy" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "imgproxy" must set securityContext.capabilities.drop=["ALL"])

Changes Made

• Added podSecurityContext and containerSecurityContext parameters in the deployment YAML file.
• Updated values file with the new parameters.
• Updated Changelog and readme

Testing

• Manually tested the application deployment using minikube with restricted Pod Security Admission level enabled.

Checklist

• [x] Added podSecurityContext and containerSecurityContext parameters.
• [x] Update changelog and documentation
• [x] Tested the deployment in a minikube environment with restricted Pod Security Admission level.

[Schreglmann]

@DarthSim @dragonsmith could you take a look at this? I'm currently not able to deploy to a cluster with high security requirements and this PR would solve my problems. Thanks.

[nhh]

@DarthSim @dragonsmith Same over here, this seems like a very mergable pr!

@mustaphaaa Maybe the breaking change is a blocking thing here, what about not renaming the pod sec ctx and just add the container security context?

[mustaphaaa]

@nhh I don't see a breaking change. I renamed the variable securityContext to podSecurityContext and added another variable for containerSecurityContext Could you please clarify where you see a breaking change?

[nhh]

@mustaphaaa Do people need to edit variable names with your change?

[mustaphaaa]

@nhh Yes, with this change, users of the Helm chart will need to update the variable names accordingly to align with the new naming. What would you propose as a solution to avoid this and maintain compatibility for the users? I can keep the variable name as it is and add the one for containerSecurityContext as you suggested before, but I think it might be confusing