Security best practices in Knative serving

This document describes how to configure Knative serving and its major components following security best practices.

Securing Knative serving

Knative serving is based on the open source Knative project, and inherits its security posture.

Workloads running on Knative serving share the same network and compute nodes. You should create separate clusters for workloads that don't have mutual trust. Knative serving clusters should not run unrelated workloads like CI/CD infrastructure or databases.

Reasons to create multiple clusters for Knative serving workloads include:

• Separating development from production environments.
• Isolating applications owned by different teams.
• Isolating highly privileged workloads.

Once you've designed your clusters, take the following actions to help secure them:

• Restrict access to your cluster.
• Understand the Knative threat model.
• Read the Knative security reference if you plan to use community supported tooling.

Securing components

You are responsible for securing components that aren't part of Knative serving.

Cloud Service Mesh

Knative serving relies on Cloud Service Mesh for routing traffic.

Use the following guides to help you secure Cloud Service Mesh:

• Cloud Service Mesh security overview and features.
• Cloud Service Mesh security best practices.

Google Kubernetes Engine

Knative serving uses Google Kubernetes Engine (GKE) to schedule workloads. Take the following actions to help you secure your clusters:

• Follow the GKE Enterprise security tutorial.
• Understand the Google Kubernetes Engine multi-tenancy model.
• Follow the Google Kubernetes Engine cluster hardening guide.
• Understand the Google Kubernetes Engine shared responsibility model.

Known vulnerabilities

You should subscribe to the security bulletins for Knative serving dependencies so you can keep up-to-date with known vulnerabilities:

• Cloud Service Mesh security bulletins.
• GKE Enterprise security bulletins.