KCSA Part 2: Kubernetes Security Fundamentals

In part two of the KCSA blog series, you'll learn about the second domain objective for the Kubernetes and Cloud Security Associate (KCSA) certification - Kubernetes Security Fundamentals.

Throughout this blog post, I’m going to explain each section of the domain/objective and put links into the direct Kubernetes docs. As I’m sure you can imagine, they’re vast topics and would end up being far too long to cover them all in one blog post.

Part 1 of this blog series can be found here: https://dev.to/thenjdevopsguy/kcsa-blog-series-part-1-overview-of-cloud-native-security-2pbh

Special Announcement: I will be officially creating the KCSA course for LinkedIn Learning! It’ll be released most likely in Q3 or Q4 of 2023, so although it’s a ways out, it makes sense from a scheduling perspective as the certification should be out of beta around that time.

Pod Security Standards

Pod Security Standards are a set of standards that cover the security spectrum at a high level. The three primary standards are:

1. Privileged
2. Baseline
3. Restricted

Privileged is completely unrestricted. It’s pretty much full-blown admin/root access. The fact that Privileged is completely open by default is open purpose. The standard is meant for system workloads that are managed by users that have the proper authentication and authorization rights.

Baseline is minimal restriction. Not too much, but not as loose as privileged. It’s primary role is to implement ease of adoption, but at the same time block any known privilege escalations.

Restricted is completely locked down. It follows the Pod hardening best practices. Restricted is geared towards apps that need heavy security due to the fact that it will block some compatibility. An example is all containers must run as non-root.

You can find more at the official page here: https://kubernetes.io/docs/concepts/security/pod-security-standards/

Pod Security Admission

Pod Security Admission defines isolation levels for Pods. Essentially, it lets you define how you want your security to look for Pods running inside your environment.

If you’ve ever looked at a Security Context in a Pod spec, or if you haven’t, take a look at the code below.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

The above code is an example from the Kubernetes docs. Take a look at the second to last line, securitycontext.

The Pod Security Admission puts requirements on said security context based on the Pod Security Standards (Privileged, Baseline, and Restricted).

Pod Security Admission is based on admission controller to ensure that the Pod Security Standards are being met.

You can find more information here: https://kubernetes.io/docs/concepts/security/pod-security-admission/

Pod Security Policy

It looks like the Linux Foundation still has Pod Security Policies on the domain objectives, but PSP has been deprecated in v1.21 and removed in v1.25 of Kubernetes. With that being said, there aren’t even official docs for it anymore per the screenshot below.

However, if PSP does come up on the exam, just remember that it’s a policy enforcer similar to Kyverno or Open Policy Agent (OPA).

API Access Control

Access Control for the API server breaks down into a few different parts:

• Authentication
• Admission Controllers
• Authorization
• Certificate signing
• Service accounts
• Kubelet authentication

From a user and team authentication perspective, the authentication piece is the same as Service Accounts. Although Kubernetes has a way to manage Service Accounts the k8s API, it does not have a way to manage user accounts. Because of that, you’ll typically (in production) see this done with an OIDC solution like Azure Active Directory or AWS IAM. Without an OIDC solution, you’ll use a combination of Linux users and certificates on Linux. The Linux user would be created along with a valid certificate from a CA (it can be something like LetsEncrypt) and that cert would be associated with the user and then presented to Kubernetes. Service Accounts are easier though because you can manage them the same way you can any other Kubernetes resource.

Once authentication is complete, authorization needs to occur. Authorization is what’s used to give the user or Service Account appropriate permissions to access Kubernetes resources. You’ll learn about authorization in the next section.

You can learn more here: https://kubernetes.io/docs/reference/access-authn-authz/

RBAC

As mentioned in the previous section, Role Based Access Control (RBAC) is a method of setting up proper authorization/permissions for users, teams, and service accounts. The goal with RBAC is to ensure that users, teams, and service accounts have the PROPER permissions. That means you don’t want users to have permission outside of what they actually need. If they’re a developer and only need to read Pods, they shouldn’t have write permission or read permission to Services.

Some best practices to follow for RBAC are:

• Least privilege.
• Minimize distribution of privileged tokens.
• Constantly review permissions for users.

You can find more information here: https://kubernetes.io/docs/concepts/security/rbac-good-practices/

Secrets

Kubernetes Secrets are another native k8s resource that’s in the Core API group. You can use the resource to create secrets that contain any information you don’t want as plain-text. This can be passwords, API keys, and anything else that you don’t want in plain-text.

Although this may not be on the test, it’s important to understand that although k8s secrets are used to ensure secrets aren’t in plain-text, they’re actually stored in plain-text in Etcd (the Kubernetes datastore). Because of this, a lot of engineers (and even some of the Kubernetes docs) recommend you to use a third-party secrets provider. A good and popular one in the Kubernetes space is HashiCorp Vault.

You can find more information here: https://kubernetes.io/docs/concepts/configuration/secret/

Multitenancy

A “tenant” in both single and multitenancy can be:

• Users
• A team
• An app
• An application stack

From a “singletenancy” perspective, it would mean one user per cluster or one application per cluster. From a multitenancy perspective, it means multiple users or a team on a cluster or multiple applications.

You’ll typically see multitenancy done because it saves costs, but it’s a security risk because you’re sharing that cluster with multiple people or multiple apps, which increases the attack surface.

With proper RBAC, authentication, and following best practices like utilizing policy enforcement, you can minimize the attack surface, but like with all security, you can never stop all attacks.

You can find more information here: https://kubernetes.io/docs/concepts/security/multi-tenancy/