Scale to Zero

OpenFaaS can scale functions down to zero replicas when idle with the faas-idler component to save resources and scale them back up on demand. In OpenFaaS Pro, you simply mark functions with com.openfaas.scale.zero=true to opt in to this behavior. In the Community Edition, scale to zero can be enabled by deploying faas-idler and labeling functions accordingly. When enabled, an idle function (no requests for a configured duration, e.g., five minutes) will be scaled down to zero pods, and the next request will cold-start the function by scaling it back up. Cold starts add a bit of latency, so use this feature judiciously for non-latency-sensitive workloads.

Manual Scaling

A function can also be scaled manually, if needed (e.g., pre-warm more replicas in anticipation of a load spike). Because functions are just Kubernetes Deployments, you can use kubectl or faas-cli to scale:

kubectl scale deploy -n openfaas-fn figlet --replicas=3

This command sets three replicas for the figlet function. The OpenFaaS gateway will respect this parameter (i.e., it won't scale down below three on its own if you've set the minimum with this manual action because it updates the Deployment). The command

faas-cli scale figlet --replicas=3

demonstrates the CLI scale command.

Security Best Practices

Running serverless functions on your infrastructure introduces security considerations at the platform level (OpenFaaS and Kubernetes) and the function level (your code). OpenFaaS, being Kubernetes-native, inherits many of the Kubernetes security features and adds its own safeguards. The following are key security best practices to consider for an OpenFaaS deployment, including access control and network restrictions.

Gateway Authentication and Access Control

As discussed, OpenFaaS gateway comes with basic authentication enabled by default. Always keep authentication enabled on the gateway, especially if the gateway is exposed on a public network. Use a strong, randomly generated admin password and rotate it, if needed. (You can update the Kubernetes secret and restart the gateway.)

If you have multiple users or teams deploying functions, consider leveraging Kubernetes role-based access control (RBAC). You can control access to the OpenFaaS Kubernetes resources (e.g., Function custom resource definitions (CRDs) or Deployments) via Kubernetes roles. The OpenFaaS Pro operator uses a Function CRD with RBAC, meaning users could be granted permission to create or update functions in specific namespaces, rather than sharing the admin gateway credentials. In the Community Edition, you might achieve something similar by controlling who can call the OpenFaaS REST API or faas-cli (perhaps by not exposing the gateway externally and only allowing anyone through a proxy or API gateway under your control).

Traffic Encryption (TLS)

Enable TLS encryption for any client traffic to the OpenFaaS gateway. If you deployed on Azure Kubernetes Service (AKS) with a LoadBalancer service type, the gateway endpoint is HTTP by default. The simplest way is with an Ingress Controller (e.g., NGINX or Traefik) with cert-manager to automatically fetch Let's Encrypt certificates. The OpenFaaS docs [3] recommend using an Ingress with TLS termination for production. For example, you might deploy NGINX Ingress, configure a host such as faas.example.com for the gateway, and let cert-manager generate a certificate for it. Alternatively, the OpenFaaS gateway can be configured with TLS directly, but managing certificates by Kubernetes Ingress is more common.

Network Restrictions and Isolation

By default, any pod in Kubernetes can talk to any other pod (unless restricted by NetworkPolicies). In an OpenFaaS context, you might want to limit network access in a few ways:

• Namespace Isolation: If you have multiple function namespaces (for different environments or tenants), consider applying Kubernetes NetworkPolicies to prevent functions in one namespace from calling functions in another or from directly calling the OpenFaaS gateway in unauthorized ways. For example, you can allow traffic from the gateway to functions, but disallow cross-namespace function-to-function traffic.
• Restrict External Access: If certain functions should not access the Internet (for compliance or safety), use NetworkPolicy to block egress from those function pods to external IPs, except perhaps to specific services.
• API Server Access: By default, OpenFaaS functions are not given permissions to talk to the Kubernetes API. The OpenFaaS RBAC rules ensure functions run with a limited service account that cannot read or write Kubernetes resources. This good security measure prevents a compromised function from manipulating cluster infrastructure. Only grant a function access to the API if absolutely necessary by creating a custom RBAC role and attaching a service account to that function's deployment.

Pod Security and Function Isolation

OpenFaaS implements several pod-level security best practices out of the box. The OpenFaaS core components (gateway, watchdog, etc.) run as non-root users. Additionally, the official function templates (for Python, Node.js, etc.) use a non-root user to run your code. This means that even if an attacker breaks out of your function code, they have less privilege on the host. You should stick to these templates or ensure your Dockerfiles use non-root users. The Helm chart even has a setNonRootUser=true option that forces functions to run as non-root as a safety net.

OpenFaaS does not allow deploying functions with privileged mode by design. Running privileged containers (which have host root access) would be a major security risk. By disallowing it, OpenFaaS ensures no function can unintentionally gain such access.

Support for read-only root filesystems for functions means your function's container filesystem (aside from a tmp directory) can be mounted read-only, preventing the function code or libraries from being modified during runtime. A read-only filesystem can be enabled by an annotation or label on the function deployment. This hardening practice is prudent if your function doesn't need to write to disk (or only to /tmp), because it protects against certain tampering and persistence techniques an attacker might use if they manage to exploit a function.

Although not a security feature per se, always set memory and CPU limits for your functions to prevent a malfunctioning or malicious function from consuming excessive resources (which could be a denial-of-service (DoS) vector). OpenFaaS templates often come with some default resource requests and limits in the YAML file. Review and adjust these on the basis of your capacity.

Secure Secrets and Credentials

Functions often need credentials or tokens (for databases, APIs, etc.). OpenFaaS integrates with Kubernetes Secrets to make them secure. Either of the commands

faas-cli secret create <name>
kubectl create secret

stores secrets in the cluster. For example,

echo -n 'my-api-key' | faas-cli secret create api-key

stores the secret in the openfaas-fn namespace by default.

Image Management and Supply Chain

Because OpenFaaS runs Docker images as functions, ensure your images come from a trusted source. If your functions are proprietary, push images to a private registry and use image pull secrets to let OpenFaaS fetch them. Create a Kubernetes Secret of type docker-registry and either attach it to the service account or specify it per function. If you use OpenFaaS templates, keep them updated to get security fixes (the templates are essentially base images with the watchdog) and scan Images for vulnerabilities as part of your continuous integration and continuous deployment (CI/CD) pipeline.