GSP482

Overview

In this lab you will learn how Kubernetes Engine security features can be used to grant varying levels of privilege to applications based on their particular requirements.

When configuring security, applications should be granted the smallest set of privileges that still allows them to operate correctly. When applications have more privileges than they need, they are more dangerous when compromised. In a Kubernetes cluster, these privileges can be grouped into the following broad levels:

• Host access: describes what permissions an application has on it's host node, outside of its container. This is controlled via Pod and Container security contexts, as well as app armor profiles.
• Network access: describes what other resources or workloads an application can access via the network. This is controlled with NetworkPolicies.
• Kubernetes API access: describes which API calls an application is allowed to make against. API access is controlled using the Role Based Access Control (RBAC) model via Role and RoleBinding definitions.

In the sections below, you will explore three scenarios with distinct security requirements at each of these levels:

Scenario	Host Access	Network Access	Kubernetes API Access
Hardened Web Server (NGINX)	Minimal	Must be able to serve port 80	None
Kubernetes Controller (Demo)	Minimal	Must be able to access the API Server	List and Patch Pods
Privileged Daemonset (AppArmor Loader)	Privileged	None	None

This lab was created by GKE Helmsman engineers to give you a better understanding of GKE security. You can view this demo by running gsutil cp -r gs://spls/gke-binary-auth/* . and cd gke-binary-auth-demo command in cloud shell. We encourage any and all to contribute to our assets!