Skip to main content
Back to Library
mastering ckad certified kubernetes application developer

Security Context and ServiceAccounts

2 min read Chapter 49 of 87
Summary

Introduces the security primitives that control what a...

Introduces the security primitives that control what a container is allowed to do at runtime (SecurityContext) and what identity it presents when communicating with the Kubernetes API (ServiceAccount). Connects both topics to the CKAD Application Environment, Configuration, and Security domain.

Security Context and ServiceAccounts

Chapter 16 covered how to externalize configuration and protect sensitive data with Secrets. But configuration management is only one dimension of application security. Two questions remain: what is a container permitted to do at runtime, and what identity does a Pod present when it talks to the Kubernetes API?

SecurityContext answers the first question. By default, a container in Kubernetes runs as root (UID 0) with the full set of Linux capabilities. This means a compromised application can modify the container filesystem, bind to privileged ports, escalate privileges, and — in worst-case scenarios with misconfigured node isolation — escape to the host. SecurityContext settings let you lock down containers: run as a non-root user, drop Linux capabilities, mount the root filesystem as read-only, and prevent privilege escalation. These settings are declared in the Pod spec and enforced by the container runtime.

ServiceAccounts answer the second question. Every Pod in Kubernetes runs with a ServiceAccount identity. By default, Kubernetes assigns the default ServiceAccount in the Pod’s namespace and mounts an API token into the container at /var/run/secrets/kubernetes.io/serviceaccount/token. That token lets the container authenticate to the API server. Combined with RBAC (Role-Based Access Control), you control exactly what API operations a Pod is authorized to perform — listing Pods, creating ConfigMaps, reading Secrets, or nothing at all.

Both topics are tested within the CKAD “Application Environment, Configuration, and Security” domain. Exam tasks may ask you to configure a Pod that runs as a specific user ID, drop all capabilities, or create a ServiceAccount with specific RBAC permissions and assign it to a Pod.

What This Chapter Covers

The following sections provide:

  • Pod and Container Security Context: Configuring runAsUser, runAsNonRoot, runAsGroup, fsGroup, readOnlyRootFilesystem, allowPrivilegeEscalation, and Linux capabilities. Complete YAML for a locked-down container with verification commands.

  • ServiceAccounts and RBAC Basics: Creating ServiceAccounts, assigning them to Pods, disabling automatic token mounting, and configuring RBAC Roles and RoleBindings to grant scoped API access. Testing permissions with kubectl auth can-i.

Master these two areas and you close one of the most commonly missed gaps on the CKAD exam.