Securing Applications on Kubernetes Engine - Three Examples
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 on Github here. We encourage any and all to contribute to our assets!
Join Qwiklabs to read the rest of this lab...and more!
- Get temporary access to the Google Cloud Console.
- Over 200 labs from beginner to advanced levels.
- Bite-sized so you can learn at your own pace.