Five security tips for OpenFaaS on Kubernetes

Project founder Alex Ellis will walk you through 5 different security features and configurations for OpenFaaS on Kubernetes

I started OpenFaaS in late 2016 as a side-project with an aim to bring the Serverless experience to developers anywhere, whatever platform they were using. The corner-stone for this initial work was the container image and Docker to help orchestrate and build fault-tolerant, highly-available and secure clusters. Fast forward to 2019 and the community now has over 240 contributors and we’ve built a solid story for Serverless on Kubernetes.

I’ll walk you through some concepts and features that can make your deployment of OpenFaaS even more robust.

1. Authentication

OpenFaaS comes with authentication turned on by default. You will be issued with, or will create a password for the admin user as part of the deployment process, whether you use Kubernetes or Swarm.

There are three modes of authentication available for the administrative endpoints of the OpenFaaS Gateway:

Basic authentication (using a community plugin)
OAuth2 with OIDC (using a plugin by OpenFaaS Ltd)
Write your own plugin

Authentication plugins can be built by anyone. The project has provided two, which cover the needs of the current users. If you have additional needs or requirements, please do get in touch, or write your own.

OAuth2 with OIDC in OpenFaaS Diagram by Alex Ellis, OpenFaaS Ltd

Whatever plugin you decide to use, it’s not just highly recommended, but essential that you also enable TLS when accepting requests from external, untrusted networks. Some users may even want to use TLS within an air-gapped environment.

Note: OpenFaaS is designed to be a modular component, that can run anywhere easily. OpenFaaS Cloud is a complete platform that ships with both TLS and OAuth2 out of the box.

Compare: OpenFaaS vs OpenFaaS Cloud

2. Transport Layer Security (TLS)

Transport Layer Security or TLS as it’s commonly known is a protocol which was introduced to encrypt traffic between services over networks. According to Wikipedia it can help mitigate eavesdropping and man-in-the-middle attacks. Today we’re talking about the TLS commonly found on web-servers, mobile apps and in software for instant messaging.

TLS relies on certificates issued by a certificate authority (CA) and if you’ve tried to create your own TLS certificates, you may be aware with how complicated this can be.

For development and testing a self-signed certificate can be used which is signed by a fictitious certificate authority (CA). When using this kind of certificate developers will need to “trust” that CA on their local computer, or configure an “insecure TLS” or “don’t verify TLS” setting in their software. It is not ideal and can be cumbersome.

The second experience of TLS that many of you may be aware of is to obtain a certificate from a CA which is already trusted by your computer. Trusted CAs typically form part of a bundle that is long-lasting and distributed with your computer. On Alpine Linux this is the ca-certificates package that can be installed. In the recent past, obtaining such a certificate could be costly, but a project call LetsEncrypt has started to give away free certificates that last for 3 months.

Rather than force developers to set up or configure TLS, we give them the option and heavily encourage it.

TLS Diagram by Stefan Prodan, showing OpenFaaS with TLS provided by cert-manager

See the following guides to set up TLS:

Once configured for your OpenFaaS Gateway, all traffic is encrypted with TLS between the client and the gateway.

Note: OpenFaaS is designed to be a modular component, that can run anywhere easily. OpenFaaS Cloud is a complete platform that ships with both TLS and OAuth2 out of the box.

Compare: OpenFaaS vs OpenFaaS Cloud

Can we make things better?

The community has proposed a feature to install OpenFaaS using the faas-cli. If this was completed, it could move us closer to being able to install TLS by default. The main drawback with this approach, is that it depends on users having a valid domain name available for use. If you’d like to see this or help work on it, then comment on the issue.

2.1 Mutual TLS (mTLS)

Traditionally applications used TLS to encrypt traffic between the client and the edge of their network. This is called TLS edge-termination and means that traffic within the cluster may be vulnerable to eavesdropping from insiders.

Mutual TLS can be enabled through a service mesh tool like Linkerd or Istio to provide encryption end to end, right from the client all the way to the block of code that executes on a particular server and back again. The encryption is achieved by attaching a proxy to every Pod in the Kubernetes network, this means that the existing unencrypted traffic must pass through the proxy to access any other service. The proxy implements the mTLS functionality.

mTLS with Istio by Stefan Prodan

mTLS is not free and comes at a cost. The project community currently prefers Linkerd for its ease of use and relatively low resource requirements, but both Linkerd and Istio are supported.

When you combine the existing stack in OpenFaaS of Prometheus, NATS and Kubernetes with Linkerd, you get: PLONK.

P - Prometheus - timeseries and metrics
L - LetsEncrypt and/or Linkerd - TLS, mTLS and service mesh
O - OpenFaaS - run any microservice or function, your next generation of PaaS
N - NATS - asynchronous messaging for background processing
K - Kubernetes, where would we be without it for portable, scalable compute?

Read my blog post: Introducing the PLONK Stack for Cloud Native Developers to find out more.

3. Kubernetes authentication and CRDs vs. OpenFaaS REST API

OpenFaaS can also rely on Kubernetes features such as role-based authentication control and the existing Kubernetes authentication strategy. This means that you can give developers very granular access to the Function CRD, just like any other Kubernetes object.

When you swap the OpenFaaS REST API for CRDs and kubectl:

Pros:

Granular access and RBAC
No additional TLS needed, relies on Kubernetes for this
No additional auth, handled by Kubernetes

Cons:

Harder to use / set up

The OpenFaaS CRD is available with the OpenFaaS Operator and is an option during installation from the helm chart.

Traditionally you would managed functions using the OpenFaaS CLI and REST API, but if we move away from the REST API and use CRDS, then you can use the faas-cli and kubectl together instead.

See also, the faas-cli generate command:

A minimal Function for openfaas.com/v1alpha2 CRD

apiVersion: openfaas.com/v1alpha2
kind: Function
metadata:
  name: nodeinfo
  namespace: openfaas-fn
spec:
  name: nodeinfo
  image: functions/nodeinfo:latest

How to generate a CRD entry from a stack.yml file:

# create a go function for Docker Hub user `alexellis2`
faas-cli new --lang go --prefix alexellis2 crd-example

# build and push an image
faas-cli build -f crd-example.yaml
faas-cli push -f crd-example.yaml

# generate the CRD entry from the "stack.yml" file and apply in the cluster
faas-cli generate -f crd-example.yaml | kubectl apply -f -

Generate a CRD from the Function Store

# find a function in the store
faas-cli store list
...

# generate to a file
faas-cli generate --from-store="figlet" > figlet-crd.yaml
kubectl apply -f figlet-crd.yaml

4. Least privilege access for OpenFaaS Core Components

The OpenFaaS Core Components have well-defined RBAC rules and access control. At this time a Role exists which is scoped to only operate in namespace containing your functions such as openfaas-fn.

Some projects ship with a ClusterRole which can give broad, unmetered access to resources in your whole cluster.

Find out how to install and manage OpenFaaS for several different teams or environments for CI/CD:

Diagram by Stefan Prodan

5. Best practices for Pods

OpenFaaS implements a number of best practices for Kubernetes Pods, the Pod is where your function or microservice will execute.

Privileged mode is not allowed

Any containers deployed with “privileged mode” on Kubernetes, if compromised could do significant damage. This flag is not available in OpenFaaS.

Non-root users

The OpenFaaS core components run as non-root users to reduce attack surface.

Templates contain a Dockerfile and an entrypoint, which is usually a HTTP server. These allow developers to avoid repeating themselves with hundreds of lines of Kubernetes YAML, instead they get 3-4 lines in a CRD or OpenFaaS stack.yml file. The official OpenFaaS templates use a non-root user so that functions are running as normal users.

See an example: openfaas-incubator/node10-express-service

An additional flag setNonRootUser for the OpenFaaS components on Kubernetes can be set to force all workloads to run as a non-root user, which is a useful catch-all if using third-party templates.

Wrapping up

The OpenFaaS values are: developers-first, operationally-simple and community-centric. For this reason we decided to make OpenFaaS modular and easy to install for developers. At present TLS is not included by default, but authentication is as a catch-all for unprotected servers on the internet.

We have provided guides, free online training workshops, and tutorials to help developers get a basic level of security, and then a production-readiness guide for administrators and SREs to start building a solid production environment.

Here’s a Tweet thread that I published today, to try to summarise our approach:

The OpenFaaS philosophy is to make the experience easy for developers and operators.

Deploying a helm chart is not deploying to production.

A production readiness guide exists to help those new to Kubernetes get ready.https://t.co/iuJRhG2DtL
— Alex Ellis (@alexellisuk) August 29, 2019

The core value of being community-centric means that suggestions, feedback and feature requests are welcomed. The more context about your use-case that you can provide, the better.

Now there are already several dozen OpenFaaS users in our end-user community, but many more who couldn’t share their logo, or who can’t talk publicly about what software they use.

OpenFaaS end-user community

If you’d like to hear from the end-user community directly, then please join Slack, or watch one of their videos from KubeCon.

Connect with us

Connect with us to discuss this blog post, or to share what you’re building with OpenFaaS.

Join OpenFaaS Slack community
Follow @OpenFaaS on Twitter