This intermediate lab is for those who want to understand how to secure cloud native applications on a Kubernetes cluster.
Lab components
This lab is for those who want to deepen their knowledge of security for cloud native applications on a Kubernetes cluster. It’s a great supplement to Lab 7 – Introduction to Kubernetes Security. Complete Lab 8 to learn all about additional security topics in Kubernetes, including authentication, runtime security, encryption and more!
The lab consists of two sections. The first covers intermediate-level Kubernetes Security theory, and the second provides hands-on keyboard command line experience. Each section is approximately 30 minutes long; however, your time may vary, depending on how quickly you pass either section. There are a total of 9 challenges to complete during this lab.
Important: On multiple-choice questions, note that more than one answer may be correct. The lab is timed, so it’s best to complete it in one sitting.
This section will cover intermediate topics and terminology for Kubernetes security. Each topic will review material on-screen, then pose a challenge question. You must answer the question correctly to proceed to the next section.
The theory section includes the following topics:
Kubernetes uses client certificates, bearer tokens or an authenticating proxy to authenticate API requests through authentication plugins.
The API server can be configured with one or more authentication plugins. The server reviews the list of authentication plugins to examine the request and determine who's sending it.
First, the request is authenticated via an authentication plugin, Then, it’s authorized by an authorization plugin and intercepted by an admission controller. Finally, the request is persisted in the etcd, which is the stateful component that stores the cluster's state and configuration.
Admission controllers are Kubernetes-native features that help you define and manage what is allowed to run on the cluster. For example, you may want to enforce security policies, manage deployment resources or even block vulnerable images from being deployed.
Several authentication plugins are available. They obtain the identity of the client using the following methods:
Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.
The RBAC authorization rules are configured through four resources, which can be grouped into two groups:
Roles define what can be done, while bindings define who can do it.
The distinction between a Role and a ClusterRole, or between a RoleBinding and a ClusterRoleBinding, is that the Role and RoleBinding are namespaced resources, whereas the ClusterRole and ClusterRoleBinding are cluster-level resources (not namespaced).
Kubernetes runtime security is the protection of containers (or pods) against active threats once the containers are running.
Runtime security helps protect workloads against a variety of threats that could emerge after containers have been deployed, such as:
Tools for Kubernetes runtime security fall into two main categories:
The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly permissive to highly restrictive.
Profile |
Description |
Privileged |
Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. |
Baseline |
Minimally restrictive policy, which prevents known privilege escalations. The baseline allows the default (minimally specified) pod configuration. |
Restricted |
Heavily restricted policy, following current pod hardening best practices. |
Kubernetes offers two ways to enforce these standards: Pod Security Admission and Pod Security Policies.
The Pod Security Admission controller is a built-in beta feature as of v1.23 and a successor to PodSecurityPolicies.
Pod Security restrictions are applied at the namespace level when pods are created.
Pod Security Admission places requirements on the Pod Security Context and other related fields according to the three levels defined by the Pod Security Standards: privileged, baseline and restricted.
A Pod Security Policy is a cluster-level resource that controls security-sensitive aspects of the pod specification.
The PodSecurityPolicy objects define a set of conditions that a pod must run with an order to be accepted into the system, as well as defaults for the related fields.
PodSecurityPolicy is deprecated as of Kubernetes v1.21 and will be removed in v1.25. Therefore, it is recommended to use Pod Security Admission instead.
Protection of secret data largely comes down to what depths we're willing to go to make it secure. There are three layers of encryption:
In this section, you will use hands-on commands to support using Roles and RoleBindings, as well as configuring a container’s security context and encrypting secrets. Each section of the hands-on exercise will provide the most important commands you need to build a solid Kubernetes security profile for applications using common commands.
Yes. Be sure to complete reading and studying this blog post, the video showing the work to be performed during the lab, and the accompanying slides. If you haven’t already, it’s helpful to complete lab 7 –Introduction to Kubernetes Security.
Go to Learning.Kasten.io to start the lab. All the best. Enjoy!
To extend your learning experience, Kasten offers a variety of resources such as whitepapers, case studies, datasheets and eBooks on Kubernetes backup. Follow this link to explore these learning materials!
Do you want to try the new dark mode?
Connect with other users and Kasten support on Kasten’s Learning Slack Channel.
We use cookies on our site to give you the best experience possible. By continuing to browse the site, you agree to this use. For more information on how we use cookies, see our Privacy Policy.
5 STARS!