Security Overview

Here we cover security aspects of running your flyte deployments. In the current state we will be covering the user which is used for running the flyte services and we will go through why we do this and not run them as root user

Why non-root user

Flyte uses docker for container packaging and by default its containers run as root. This gives full permissions on the system but may not be suitable for production deployments where a security breach could comprise your application deployments. It’s considered to be a best practice for security because running in constrained permission environment will prevent any malicious code from utilizing the full permissions of the host Ref Also in certain container platforms like OpenShift running non-root containers is mandatory.

Changes

New user group and user have been added to the Docker files for all the flyte components Flyteadmin Flytepropeller Datacatalog Flyteconsole

And Dockerfile uses USER command which sets user and group which will be used for running the container.

Additionally the k8s manifest files for the flyte components define the overridden security context with the created user and group to run them. Following shows the overriden security context added for flyteadmin Flyteadmin

Why override

There are certain init-containers that still require root permissions and hence we required to override the security context for these. For example: in case of Flyteadmin the init container of check-db-ready that runs postgres-provided docker image is not able to resolve the host for the checks and fails. This is mostly due to no read permissions on etc/hosts file. Only the check-db-ready container is run using the root user and which we will plan to fix as well.