Security Overview#

Tags: Kubernetes, Infrastructure, Advanced

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

Why non-root user#

Flyte uses docker for container packaging, and by default, its containers run as root. This gives full permissions to 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 a 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#

A new user group and user have been added to the Docker files for all the flyte components Flyteadmin, Flytepropeller, Datacatalog, Flyteconsole.

And Dockerfile uses the USER command, which sets the user and group, that’s 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. The following shows the overridden security context added for flyteadmin Flyteadmin.

Why override#

Certain init-containers still require root permissions, and hence we are required to override the security context for these. For example: in the case of Flyteadmin, the init container of check-db-ready that runs postgres-provided docker image cannot 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, which we will also plan to fix.

OAuth#

Flytectl requires CA-certified SSL cert for OAuth to work. Using a self-signed certificate throws the following error:

certificate is not standards compliant.

There are two options to fix this:

  1. Switch to a full external OAuth Provider (okta, GCP cloud identity, keycloak, Azure AD, etc.).

  2. Use a CA-certified SSL cert.

Running flyteadmin and flyteconsole on different domains#

In some cases when flyteadmin and flyteconsole are running on different domains then you would need to allow the flyteadmin’s domain to allow cross origin request from the flyteconsole’s domain This can be done by changing the flyteadmin config in the following manner

  1. <flyte-admin-domain> is the domain which will be get request

  2. <flyte-console-domain> is the domain which will be sending the request as the originator

  3. <flyteconsole-ns> k8s namespace where your flyteconsole pod is running.

  4. <flyteadmin-ns> k8s namespace where your flyteadmin pod is running.

  5. Modify the flyteconsole deployment to use <flyte-admin-domain> as follows.

    kubectl edit deployment flyteconsole -n <flyteconsole-ns>
    
    - env:
      - name: ENABLE_GA
        value: "true"
      - name: GA_TRACKING_ID
        value: G-0123456789
      - name: ADMIN_API_URL
        value: https://<flyte-admin-domain>
    
  6. And then rollout flyteconsole

    kubectl rollout restart deployment/flyteconsole -n <flyteconsole-ns>
    
  7. Modify the flyte-admin-config as follow

    kubectl edit configmap flyte-admin-config -n <flyteadmin-ns>
    
    security:
      allowCors: true
      ......
      allowedOrigins:
      - 'https://<flyte-console-domain>'
      ......
    
  8. And then rollout admin

    kubectl rollout restart deployment/flyteadmin -n <flyteadmin-ns>