Proposal: Ability to set runAsUser to deployed functions

[rmb938]

Summary

https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Sometimes a Kubernetes cluster is configured with certain Pod Security Polices in place. This includes denying running as privileged, having to run as a certain user, ect...

Being that faas-netes does not set privileged mode on functions, mount any pvc's, ect... it's mostly fine however there is still the requirement to run as a certain user, or at least not root.

Design

This can simply be achieved by adding a flag to the faas-netes controller with the id of the user to run functions as. An example would be --function-run-as-user 1000. This config will then be used in the function deployment spec for kubernetes.

Docker does support adding USER to the Dockerfile which does satisfy the runAsUser requirement defined by Kubernetes. Doing it this way allows no modifications to faas-netes, however having the option to set it via the controller is still nice to have and opens the door to other security policies being enforced.

Pros & Cons

Pros

• Adds the ability to adhere to Kubernetes Pod Security requirements.

Cons

• Adds extra configuration to faas-netes that needs to be documented.

Effort up front

Adding the extra config option, modifying the function deployment method and modifying the helm charts.

Effort for On Going maintenance

As Kubernetes adds more security policies they may have to also be added to faas-netes which may require more complex configuration.

Backwards Compatibility

Not setting the flag will default to current behavior of not setting runAsUser.

[alexellis]

OpenShift has a requirement that nothing can run as a root user, even an unprivileged root user. We are running as non-root for most of the templates and also for the core services.

I think this satisfies the requirement - can you confirm?

K8s controller:

https://github.com/openfaas/faas-netes/blob/master/Dockerfile#L34

Gateway:

https://github.com/openfaas/faas/blob/master/gateway/Dockerfile#L40

Go template:

https://github.com/openfaas/templates/blob/master/template/go/Dockerfile#L32

OpenFaaS subscribes to UNIX principles which state: convention over configuration. That is to say that user app or userid 1000 is a convention used in the project and making that configureable is not necessary or desired unless there is a strong case for doing so - i.e. some internal compliance audit for a large user / customer.

cc @stefanprodan

[rmb938]

I think you misread my proposal. This is not requiring that openfaas components run as non-root, it is simply adding a flag for functions to be forced to run as non-root. As for the template Dockerfile not all functions will be created using a template.

[milsonian]

Hi Alex, thanks for reviewing our proposals, I know we've sent a few!

Just adding a note that if 'internal compliance audit for a large customer' makes for a strong case, that is defining our need very well - fwiw. On our secure Kubernetes clusters we prevent anything running as root from starting, including in what will be a function namespace.

Since this is fairly lightweight to add, is optional (doesn't change behavior to the end user by default), and would improve user experience (allows simple local dev, portability of functions/simplicity of images, while securing downstream as necessary) it seems like a worthwhile feature to me.

[alexellis]

We don't add features that "seem worthwhile" or "easy to add" - here's why: everything has a cost - in maintenance and in complexity.

If you have a key requirement to run the functions as non-root, then we should look into it the security context in the Kubernetes API and see what's available there.

None of the functions run privileged so they don't have root on the host - if someone deploys a function that run internally as "root" that's a different thing. If you are concerned about escalation or break-out then you could put your functions through a CI or scanning system like Harbour or Clair to prevent them being promoted through to production.

I'm also happy to look into the API and see if there's something more global for the faas-netes controller and perhaps if we find something you guys could work on that.

[milsonian]

We're not suggesting the feature be added without contemplating the value and quantifying the cost. Indeed, the cost can be real.

Tools like Harbour and Clair are great, and agreed, are the preferred approach to prevent unsavory code from making it through to release (and we use them). However when dealing with enterprises running mature Kubernetes clusters at scale in production in regulated environments, additional assurance and breakout mitigation at the runtime is required.

We do use security contexts in Kubernetes (e.g. allowPrivilegeEscalation: false and runAsUser: 1000) and use pod security policies to enforce this requirement on clusters. Currently runAsUser only supports numeric IDs. Using a numeric ID in Dockerfiles (or a semi-consistent named user for that matter) is not common in most projects (and, not required in most environments). So, the ability to handle this at the platform layer has some value.

Other approaches such as this (more) are forthcoming, but we're currently working with the options in front of us.

In the end this is one of the small capabilities we are hoping to add, to get going with contributions and earn the trust of the OpenFaaS community - I think if a goal is to gain traction in additional deployments in the enterprise, simple features like this will help. It's good that OpenFaaS is gating unneeded additions/complexity, but I don't think this proposal was submitted thoughtlessly.

[alexellis]

Derek close: this has been released