I am in the process of writing a pull request to update your helm charts/templates to include the option to harden the security policy when deployed to a k8s cluster and I wanted to open this thread so I could ask you questions regarding the implementation of the product.
I am currently in the process of hardening our AKS clusters ahead of a penetration test in the coming weeks and when trying to apply the Restricted Pod Security Standards I am finding that the squidex and squidex-mongodb pods are in breach of the policy.
Warning: existing pods in namespace "squidex" violate the new PodSecurity enforce level "restricted:latest" Warning: squidex-6ccd696cd-lxvvf (and 2 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile Warning: squidex-mongodb-replicaset-0 (and 2 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, seccompProfile namespace/squidex labeled
The key restrictions here that we need to apply are:
- allowPrivilegeEscalation: false
unrestricted capabilities: all capabilities need to be dropped and only
NET_BIND_SERVICEshould be allowed
- runAsNonRoot: true
secCompProfile: while can be set quite granularly, I have found that
RuntimeDefaultto be sufficient for now
The good news
I have managed to harden the squidex pod to follow the Restricted policy and no longer get a warning for that pod for any of the above reasons, however, the MongoDB replicaset is still reporting to be an issue.
Warning: existing pods in namespace "squidex" violate the new PodSecurity enforce level "restricted:latest" Warning: squidex-mongodb-replicaset-0 (and 2 other pods): allowPrivilegeEscalation != false, unrestricted capabilities, seccompProfile namespace/squidex labeled
My actual (potentially stupid) question
How do we go about changing the implementation of the MongoDB chart included in the solution?
I am finding it currently included in the solution as a .tgz file which I could unzip and make the necessary changes but I would not want to be making changes to something that is automatically included as part of a separate pipeline elsewhere and to have the changes overwritten at a later date.
If the case is to simply unzip the folder, make the required changes and zip the files back up again I am more than happy to do so but I just wanted to check what the best practice would be for this particular part of the system.
Also, as part of my testing of the increased security, I will need to make changes to the Dockerfile which may affect other deployment methods which will need to be tested and accounted for (like running as a non-root user account and exposing only non-privileged ports (1-1024).
Would you be available to help test these deployment methods once the pull request is ready and up on GitHub?