-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Description
In order to harden the security of the applications or for hosting on EKS Fargate, one thing would be to avoid using root user.
Some challenges on this and how we might solve them:
- changing php-fpm config at runtime without giving the app the permission to do it (e.g. pool configuration)
- use an initContainer and a shared emptyDir volume within the pod, which runs as build user (also reminder that containers in a pod can have their own securityContext)
- enabling/disabling extensions at runtime (e.g. newrelic)
- same as 1 with some changes to ini files to be writeable by build?
- supervisor/php-fpm changes
- we can really remove supervisor and run php-fpm with tini anyway
- php-fpm itself can be reloaded with SIGUSER2 signal if we still need to be able to reload it at runtime without the process manager itself stopping the container
- is there any risk in running the php-fpm process manager as the same user its forks run as?
- we can really remove supervisor and run php-fpm with tini anyway
- writeablePaths chowning and how to handle different storage systems' lack of fsGroup handling
- hopefully newer storage drivers support this more
- where two users supported, if they are both share the same group there is some flexibility in chgrp without root
- not an issue on aws-efs-provisioner application endpoint dynamic provisioning since it gives all users write access
- running app-init and app-migrate jobs as build user (and ideally using the entrypoint too for tini)
- I don't see there being an issue with this. We run
app initlocally with build user
- I don't see there being an issue with this. We run
- are there any issues running cronie as non-root?
- port bindings - non-root users can't bind to ports < 1024 so things like nginx will need remapping
Metadata
Metadata
Assignees
Labels
No labels