This course 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 Course 7 – Introduction to Kubernetes Security. Complete Lab 8 to learn all about additional security topics in Kubernetes, including authentication, runtime security, encryption and more!
What is the structure of the lab?
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.
Section 1: Intermediate Security Theory
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:
- Role-based access control (RBAC) plugins
- Run-time security with security context
- Pod security standards
- Encryption and secret management
Topic 1: Authentication
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:
- X509 Client Certs
- Bearer token passed in an HTTP header
- OpenID Connect Tokens
Topic 2: Role-Based Access Control Plug-ins
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 Kubernetes API server can be configured to use an authorization plugin to check whether an action is allowed to be performed by the user requesting the action.
- Because the API server exposes a REST interface, users perform actions by sending HTTP requests to the server.
- Users authenticate themselves by including credentials in the request (an authentication token, username and password, or a client certificate).
The RBAC authorization rules are configured through four resources, which can be grouped into two groups:
- Roles and ClusterRoles, which specify what actions can be performed on which resources.
- RoleBindings and ClusterRoleBindings, which bind the roles above to specific users, groups or ServiceAccounts.
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).
Topic 3: Runtime Security with Security Context
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:
- The activation of malware that is hidden inside a container image
- Privilege escalation attacks in which a container exploits security bugs in the container runtime, Kubernetes or the host OS
- The deployment of unauthorized containers by an attacker who exploits a gap in an access control policy or a bug in Kubernetes
- Unauthorized access to secrets or other sensitive information that a running container should not be able to read
Tools for Kubernetes runtime security fall into two main categories:
- Enforcement tools: These enable you to define policies that restrict the access rights and permissions of resources within a runtime environment.
- Auditing tools: These enable you to detect and react to threats based on data collected from your cluster.
Topic 4: Pod Security Standards
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.
|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.
Topic 5: Encryption and Secret Management
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:
- Disk Encryption: Protects information at rest by converting it into unreadable code that cannot be deciphered easily by unauthorized people. This can be enabled in the filesystem and/or storage systems used by Kubernetes.
- Transport Encryption: Protects information that is actively in flight by ensuring that communication between components is encrypted. This can be achieved by having all the internal components of Kubernetes and etcd interact over TLS. By default, all traffic between the pods is not encrypted and will require an encrypted networking layer provided by Service Meshes over Mutual TLS (mTLS), such as Istio and Linkerd or Cilium.
- Application Encryption: Protects information within our system components or workloads running in Kubernetes, for example, encrypting secret objects data.
Section 2: Hands-on Commands — Intermediate Security Skills
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.
Is there pre-work for the lab?
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 Course 7 –Introduction to Kubernetes Security.