Use this guide to connect Kubernetes security controls with the problems they solve. Each concept explains a decision, demonstrates its application and identifies a specific mistake. Work through the foundations first, then reproduce the examples in an isolated practice cluster where you can inspect configuration and verify behavior.
Cluster Setup
1. NetworkPolicy isolation and additive permissions
NetworkPolicy selects pods and controls ingress, egress or both. A selected pod becomes isolated for a direction when a policy applies to that direction. Allowed traffic is the union of applicable policies; policies do not provide an ordered deny list. Communication between isolated endpoints must satisfy the source's egress rules and destination's ingress rules.
Worked example: An API pod permits ingress from frontend pods, but the frontend's egress policy permits only DNS. The connection remains blocked until frontend egress also allows the API.
Mistake to avoid: Assuming an ingress allowance overrides a restriction on the sending pod.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
2. Combining namespace and pod selectors
Within one NetworkPolicy peer entry, namespaceSelector and podSelector work together: the peer must match both. Separate peer entries create alternatives. A peer containing only podSelector selects pods in the policy's namespace. This distinction determines whether access follows a narrowly defined workload identity or a much broader set of namespaces and pods.
Worked example: To admit gateway pods only from the edge namespace, place the edge namespace selector and gateway pod selector in the same peer entry.
Mistake to avoid: Separating the selectors into entries and unintentionally permitting either matching population.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
3. DNS dependencies in restricted egress
An application can have permission to reach its backend yet fail because DNS resolution is blocked. Build egress rules around the resolver actually used by the pod. Traditional DNS may require UDP and TCP on port 53, while node-local resolvers can introduce different paths that must be checked against the networking implementation.
Worked example: A client reaches a database by IP but cannot resolve its service name. Inspection shows blocked resolver traffic; a targeted DNS allowance restores name resolution.
Mistake to avoid: Opening unrestricted egress to fix a DNS dependency without identifying the resolver.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
4. Verifying network policy enforcement
Creating a NetworkPolicy object proves that the API accepted configuration, not that traffic is filtered. Enforcement depends on the networking implementation. Verify selected pod labels, applicable policies and actual connection results. Test both an intended allowance and an intended denial using fresh connections so an existing session does not distort the result.
Worked example: A reporting pod should reach the API, while a sandbox pod should not. Both connect successfully, so the policy requires investigation rather than being accepted as effective.
Mistake to avoid: Treating the presence of a policy object as evidence of isolation.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
5. Interpreting CIS benchmark findings
A CIS benchmark turns security expectations into configuration checks. Interpret each finding against the benchmark's applicable component and version, then inspect the effective configuration. A failed check can identify a weakness, an unsupported check or a documented exception; its status alone does not establish the cause or justify an arbitrary configuration change.
Worked example: A kubelet check flags anonymous authentication. Inspecting its active configuration confirms it is enabled, establishing a specific setting to correct and verify.
Mistake to avoid: Editing an unused configuration file and assuming the running component changed.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
6. Ingress TLS and certificate identity
TLS protects a connection only when the client validates the certificate chain and intended hostname. An Ingress configuration must associate the requested host with the appropriate certificate. Also identify where TLS terminates: encryption from client to ingress does not automatically encrypt the separate connection from ingress to the backend service.
Worked example: A certificate covers shop.example.test, but the route uses checkout.example.test. Correcting the hostname or certificate resolves the identity mismatch; backend encryption remains a separate decision.
Mistake to avoid: Assuming a browser padlock proves every internal network hop is encrypted.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
7. Protecting node metadata and management endpoints
Cloud metadata services and node management endpoints can expose credentials or privileged functions beyond an application's needs. Identify reachable endpoints and restrict workload access using controls appropriate to the platform and network path. Pod networking, host networking and node traffic can follow different enforcement paths, so verify restrictions from each relevant workload context.
Worked example: A web workload has no metadata dependency. Its access is restricted, then checked separately for ordinary pods and any approved host-networked workloads.
Mistake to avoid: Assuming one pod policy necessarily protects node-originated or host-networked traffic.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
8. Authenticating platform binaries
A checksum detects whether a binary matches expected bytes, but its security depends on the checksum's source. Obtain verification material through a trusted publisher channel and validate signatures when available. Comparing a downloaded binary with a checksum from the same compromised location can confirm consistency without proving authenticity.
Worked example: A platform binary's calculated digest differs from the trusted release digest. Rejecting that file prevents deployment of an unverified artifact.
Mistake to avoid: Treating an unauthenticated checksum beside a download as independent proof of trust.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
Cluster Hardening
9. RBAC permissions and binding scope
RBAC separates permission definitions from assignments. A Role defines permissions within a namespace; a ClusterRole can define reusable namespaced permissions or cluster-scoped permissions. A RoleBinding grants applicable permissions in its own namespace, even when referencing a ClusterRole. A ClusterRoleBinding grants the referenced permissions across the cluster.
Worked example: A support group needs to read pods only in staging. A staging RoleBinding to a suitable read-only ClusterRole provides that namespace boundary.
Mistake to avoid: Using a ClusterRoleBinding when the requirement is limited to one namespace.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
10. Resource verbs and subresources
Least privilege requires matching API groups, resources, verbs and, where appropriate, resource names to a task. Subresources such as pods/log and pods/exec represent distinct access. Reading pod definitions does not automatically grant log access or interactive execution. Wildcards can silently extend permissions when additional resources or capabilities appear.
Worked example: A diagnostics account receives get on pods and pods/log. It can inspect logs without receiving create on pods/exec.
Mistake to avoid: Granting every pod subresource because ordinary pod reads are required.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
11. Recognizing indirect privilege escalation
Review what permissions enable, not just their names. Creating workloads can expose powerful service accounts or host resources unless admission controls constrain them. Permissions involving bind, escalate or impersonate can also cross intended authority boundaries. Kubernetes includes escalation protections, but a security review must still consider the combined permissions and accessible resources.
Worked example: An account cannot read Secrets directly but can create pods using a privileged service account. That workload path makes its effective access broader than its read permissions suggest.
Mistake to avoid: Equating the absence of direct Secret reads with the absence of credential access.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
12. Service account token exposure
A service account identifies a workload to the Kubernetes API. Workloads that do not use the API usually do not need automatically mounted API credentials. For workloads that do, prefer appropriately scoped, time-bound tokens and verify the intended audience. Removing a token mount reduces exposure but does not replace permission review.
Worked example: A static content server has no Kubernetes API dependency. Disabling automatic service account token mounting removes an unnecessary credential from its containers.
Mistake to avoid: Assuming every application needs an API token because it runs inside Kubernetes.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
13. Separating workload identities
Give workloads distinct service accounts when their permissions or trust boundaries differ. Sharing one identity combines authority and weakens attribution: a compromised low-trust component may use permissions intended for another component. Evaluate identity together with namespace bindings and the admission rules governing which service accounts workloads may select.
Worked example: A queue reader and a deployment controller stop sharing an account. Only the controller's new account retains permission to update Deployments.
Mistake to avoid: Creating separate account names while binding both to the same excessive role.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
14. Authentication, authorization and admission
Authentication establishes who a request represents. Authorization decides whether that identity may perform the requested operation. Admission can mutate or validate an otherwise authorized request before persistence. These controls solve different problems: an authenticated user can lack permission, and an authorized deployment can still violate workload security requirements.
Worked example: A developer may create Deployments in a namespace, but admission rejects a manifest requesting privileged containers. Authorization succeeds while workload validation fails.
Mistake to avoid: Weakening RBAC to solve an admission rejection without examining the rejected configuration.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
15. Restricting API server exposure
API security combines a protected network path, trusted TLS identity, authentication and authorization. Restrict endpoint reachability to necessary clients and administrative paths while preserving required component communication. Network restrictions reduce exposure; they do not establish the caller's Kubernetes permissions or compensate for broadly trusted credentials.
Worked example: An API endpoint accepts connections only from approved management networks. A user on that network still needs valid credentials and an authorized role.
Mistake to avoid: Treating access to a trusted network as sufficient authorization to administer the cluster.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
16. Security upgrades and compatibility
An upgrade addresses known weaknesses only if affected components actually receive the corrected software and remain securely configured. Plan against supported version relationships, API compatibility and the platform's official procedures. Confirm component versions and essential behavior afterward. For exam exercises, use the environment's documented release rather than assuming production upgrade rules are identical.
Worked example: The control plane is updated, but a worker still runs an affected kubelet release. The security remediation remains incomplete until that worker is addressed.
Mistake to avoid: Inferring cluster-wide remediation from the API server version alone.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
System Hardening
17. Reducing the host operating system footprint
Every installed service and package can introduce vulnerabilities, credentials or reachable functionality. A minimal node image should retain required runtime, networking and operational components while removing unnecessary software. Evaluate dependencies before removal: reducing the footprint is useful only when the node can still perform its intended role and receive maintenance.
Worked example: A worker image contains an unused file-sharing server. Removing that service and its unnecessary packages eliminates a listener without affecting workload execution.
Mistake to avoid: Deleting unfamiliar packages before establishing whether the container runtime depends on them.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
18. Host file ownership and permissions
Linux discretionary permissions control which identities can read, write or execute host files. Security depends on ownership, group membership and directory permissions as well as the file's mode. Sensitive configurations should be writable only by their intended administrators. Read restrictions protect secrets, while write restrictions protect the behavior of privileged processes.
Worked example: A runtime configuration is root-owned but group-writable by ordinary operators. Removing unnecessary group write access prevents those operators from changing privileged runtime behavior.
Mistake to avoid: Checking file ownership while overlooking permissive modes or writable parent directories.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
19. Least privilege for node administration
Administrative access should use identifiable accounts and only the privileges needed for the task. Shared root credentials weaken attribution, while unrestricted privilege elevation expands the effect of account compromise. Review allowed commands carefully because interpreters, editors and commands that launch other programs can provide more authority than their names suggest.
Worked example: An observer needs service status information, not general root execution. An approved read-only inspection path meets that requirement without granting unrestricted administrative access.
Mistake to avoid: Calling an elevation rule narrow without evaluating the behavior of its allowed commands.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
20. Host listeners and firewall boundaries
A host's attack surface includes both listening services and the network paths that reach them. A service bound to all interfaces can be exposed beyond its intended management network. Host firewall changes must account for cluster networking, forwarded traffic and necessary component communication; a rule's location and packet path affect its enforcement.
Worked example: A diagnostic service needs local access only. Binding it to loopback removes remote reachability while preserving local inspection.
Mistake to avoid: Blocking a port without checking whether the service is exposed through another interface or forwarding path.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
21. Linux capabilities as separate privileges
Linux capabilities divide many traditional root privileges into individual authorities. Containers should drop unnecessary capabilities and add back only demonstrated requirements. Running as a non-root user and reducing capabilities are complementary controls. A narrow-looking capability can still be powerful, so judge its operations and interactions rather than merely the size of the capability list.
Worked example: A web application listens on an unprivileged port and performs ordinary file access. Dropping all capabilities fits those requirements without adding network administration authority.
Mistake to avoid: Adding CAP_SYS_ADMIN as a general solution to unexplained permission errors.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
22. Seccomp syscall filtering
Seccomp restricts the system calls a process may make. A runtime-provided default profile offers a baseline, while a custom profile requires compatibility testing against legitimate behavior. Filtering operates at the syscall layer and does not express filesystem path permissions. Confirm the effective profile and investigate denied operations before broadening access.
Worked example: A workload requests RuntimeDefault and its ordinary requests succeed. A separate test failure is traced to a filtered syscall rather than solved by making the container privileged.
Mistake to avoid: Disabling seccomp entirely before identifying the operation that requires an exception.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
23. AppArmor confinement
AppArmor applies policy to permitted process behavior, including access to filesystem paths. Profiles must be available on the relevant nodes and attached through the supported configuration for that environment. A profile in complain mode records violations without enforcing denials; enforcement and application compatibility both require verification.
Worked example: A service should read its configuration but never modify it. An enforcing profile permits the read and denies an attempted write during validation.
Mistake to avoid: Treating logged violations from complain mode as proof that access was blocked.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
24. Distinguishing installed and running patches
Installing a corrected package does not guarantee that active processes use it. Long-running services may retain old code, and a newly installed kernel may not be running until the required activation step occurs. Remediation therefore needs evidence about the live system, with service restarts or node maintenance performed through an appropriate operational procedure.
Worked example: A node has the corrected kernel package installed, but its running kernel remains the earlier release. The kernel vulnerability is still relevant.
Mistake to avoid: Closing a security finding solely because the package manager reports an updated package.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
Minimize Microservice Vulnerabilities
25. Pod Security Standards and admission modes
Pod Security Standards describe workload security expectations at Privileged, Baseline and Restricted levels. Pod Security Admission can enforce a selected level, warn about violations or record audit annotations. These modes have different effects. Evaluate existing workloads and the policy version before enforcement so compatibility findings lead to deliberate changes rather than unexplained rejection.
Worked example: A namespace warns on Restricted violations during evaluation. Switching its applicable policy to enforce makes violating pod creation fail instead of merely generating warnings.
Mistake to avoid: Assuming a warning policy prevents insecure workloads from being admitted.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
26. Non-root execution and file access
A workload's user identity affects access to files and privileged operations. runAsNonRoot expresses a requirement to avoid root execution, while a suitable numeric runAsUser makes the intended identity explicit. Image metadata, volume ownership and application requirements must agree with that identity. Non-root execution reduces authority but does not remove every dangerous permission.
Worked example: An application runs as UID 10001 but cannot write its cache. Providing a narrowly writable cache directory fixes the dependency without restoring root execution.
Mistake to avoid: Changing the entire container to root because one directory has incorrect ownership.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
27. Preventing privilege gains during execution
allowPrivilegeEscalation: false prevents a process from gaining additional privileges through execution mechanisms such as set-user-ID programs. This control is separate from choosing a non-root identity or dropping capabilities. It does not remove privileges already granted, and privileged containers or CAP_SYS_ADMIN undermine the intended restriction; evaluate the full security context together.
Worked example: A non-root application needs no privilege-changing helpers. Its configuration disables privilege escalation and omits privileged mode and CAP_SYS_ADMIN.
Mistake to avoid: Assuming a non-root starting identity alone prevents later privilege gains.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
28. Host namespaces and host filesystem mounts
Host namespace sharing and host filesystem mounts reduce separation between workloads and nodes. hostPID can expose host process information; hostNetwork shares the host network namespace; hostPath exposes a chosen node path. Each needs a specific justification. A read-only mount prevents writes through that mount but can still expose sensitive information.
Worked example: A metrics workload requires one approved read-only host directory. Limiting the mount to that directory avoids exposing the entire host filesystem.
Mistake to avoid: Treating a read-only mount of host credentials as harmless because modification is blocked.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
29. Secret encoding and authorization
Kubernetes Secret values use base64 encoding in common API representations. Encoding is reversible and provides no confidentiality. Protect Secrets through authorization and controlled delivery to workloads. Permissions to get, list or watch Secrets can reveal their contents, while workload creation permissions may provide an indirect route to consuming them.
Worked example: An operator receives permission to list Secrets to discover names. That permission also exposes Secret data, so a different inventory approach is needed.
Mistake to avoid: Granting list access under the assumption that it reveals only object names.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
30. Encryption of persisted Secret data
Encryption at rest protects stored data against some storage exposure scenarios; it does not prevent authorized API reads. Verify the configured encryption provider and whether existing objects have been rewritten under the intended configuration. Protect encryption keys and backups separately, and plan rotation so retained ciphertext remains recoverable through the approved process.
Worked example: Encryption is enabled, but older Secret records remain stored under their previous representation. Verification reveals that existing data still needs migration.
Mistake to avoid: Assuming a configuration change retroactively rewrites every stored Secret.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
31. Secret delivery and application exposure
A securely stored Secret can still leak when an application logs it, includes it in diagnostics or exposes it through a compromised process. Compare file-based and environment-based delivery against the application's behavior. Environment values are established when the container starts; file updates also require the application to detect or reload changed values appropriately.
Worked example: A service reads its password only at startup. Updating its Secret does not change the active credential until the service follows its reload or restart procedure.
Mistake to avoid: Assuming changing a Secret immediately changes every application's in-memory credentials.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
32. Multi-tenancy as layered isolation
Namespaces organize resources and provide useful policy boundaries, but they do not independently isolate networks, kernels or storage. Multi-tenancy requires aligned RBAC, network restrictions, admission controls and resource boundaries. Stronger trust separation may require dedicated nodes or separate clusters, depending on the threat model and the controls protecting shared infrastructure.
Worked example: Two teams have separate namespaces but unrestricted pod networking. Adding appropriate network restrictions addresses a communication boundary that namespace separation alone never established.
Mistake to avoid: Calling namespaces a complete security boundary for mutually untrusted tenants.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
33. Sandboxed runtimes and RuntimeClass
A sandboxed container runtime can add isolation beyond ordinary shared-kernel containers, depending on its design. RuntimeClass selects a configured runtime handler; naming a class does not install the runtime or prove its security properties. Check node support, scheduling constraints, workload compatibility and the resulting runtime before relying on the stronger boundary.
Worked example: An untrusted parser selects an approved sandbox RuntimeClass and is scheduled onto compatible nodes. Runtime inspection confirms the sandbox actually handles the workload.
Mistake to avoid: Assuming an arbitrary RuntimeClass name automatically enables sandboxing on every node.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
34. Pod-to-pod encryption and peer identity
Pod-to-pod encryption protects data on the network, while peer authentication establishes who is communicating. These are separate properties. Cilium and Istio can provide relevant capabilities through different architectures and configurations. Determine which paths are protected, where encryption terminates and which identities authorization uses rather than assuming product installation establishes every property.
Worked example: A service permits only the billing workload identity through an authenticated encrypted connection. A different authenticated workload is still denied by authorization policy.
Mistake to avoid: Allowing every encrypted connection because encryption is mistaken for permission.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
35. Certificate trust and rotation
Encrypted service communication depends on valid certificates, trusted issuers and identities matching policy. Rotation must preserve the intended trust chain while replacing expiring credentials. Diagnose connection failures by separating expiry, issuer trust, identity mismatch and authorization rejection. Avoid bypassing certificate verification as a workaround because it removes the intended peer identity check.
Worked example: A renewed service certificate uses an issuer the client does not trust. Updating the approved trust bundle resolves the failure without disabling verification.
Mistake to avoid: Treating every TLS handshake failure as a network connectivity problem.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
36. Enforcing workload requirements at admission
Admission validation can prevent workloads with prohibited configuration from entering the cluster. Translate requirements into checks against the actual workload and relevant container fields, including init containers where applicable. Enforcement should produce understandable failures and deliberate exceptions. A manifest review helps developers, while admission provides a boundary when deployment paths bypass that review.
Worked example: A policy requires approved workload identities. A deployment selecting an unauthorized service account is rejected even though its creator may create Deployments.
Mistake to avoid: Checking only the main container while overlooking security settings elsewhere in the pod.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
Supply Chain Security
37. Minimal runtime image contents
A runtime image should contain the application and necessary dependencies without unnecessary build tools or services. Smaller contents reduce the software requiring assessment, but image size alone is not a security measure. Confirm that the retained components receive maintenance and that operational diagnostics can be performed through an approved approach.
Worked example: A compiled service moves from a development image containing compilers to a compatible runtime image. Its application dependencies remain present while unnecessary build tools disappear.
Mistake to avoid: Choosing the smallest image without checking dependency compatibility or maintenance.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
38. Build stages and confidential inputs
Multi-stage builds separate compilation from the final runtime artifact and allow selective copying of outputs. They do not automatically protect secrets: credentials may remain in intermediate layers, caches, logs or copied files. Use appropriate secret handling and inspect what is exported from each stage, including artifacts retained by the build system.
Worked example: A private dependency credential is supplied through an approved temporary build-secret mechanism. Only the compiled application is copied into the final image.
Mistake to avoid: Embedding a credential in a build argument and assuming an omitted final-stage file guarantees secrecy.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
39. Pinned dependencies and reproducible inputs
Dependency locks and pinned inputs reduce unexpected changes between builds. They support investigation by identifying what was selected, but they do not establish that a dependency is trustworthy or free of vulnerabilities. Maintain controlled updates and verify downloaded artifacts where supported. Include indirect dependencies and base images in the build's recorded inputs.
Worked example: A library update changes the lockfile through review, and the build records the selected version. Later investigation can distinguish that build from its predecessor.
Mistake to avoid: Leaving a vulnerable dependency unchanged because pinning is mistaken for permanent security.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
40. SBOMs as component inventories
A software bill of materials records components associated with an artifact, often including versions and relationships. It helps locate affected builds when a component vulnerability becomes known. Its value depends on accuracy, coverage and a reliable association with the delivered artifact. An SBOM is an inventory, not a verdict that the software is secure.
Worked example: A newly reported library issue is matched against SBOMs tied to image digests. The matching digests identify which deployed images need investigation.
Mistake to avoid: Using an SBOM from a different build because the application name is the same.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
41. Interpreting image vulnerability findings
A scanner finding connects detected software with a known issue. Triage must consider version accuracy, exploit prerequisites, workload exposure and whether a correction exists. Severity supports prioritization but does not replace context. Record justified exceptions and reassess them when dependencies, deployment conditions or vulnerability information change.
Worked example: A scanner flags a package absent from the final runtime stage. Confirming the scanned artifact reveals it was the builder image, so the runtime assessment must be corrected.
Mistake to avoid: Treating a scanner's headline severity as sufficient evidence of the deployed workload's exposure.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
42. Static workload configuration analysis
Static analysis tools such as Kubesec or KubeLinter inspect declared workload configuration for risky patterns. Their findings describe potential weaknesses, not observed runtime behavior. Analyze rendered manifests when templates are involved, understand each rule and check that proposed corrections preserve legitimate requirements. Combine analysis with admission and runtime verification.
Worked example: A template appears safe, but its rendered output enables host networking through an environment-specific value. Analyzing that output exposes the actual deployment risk.
Mistake to avoid: Scanning only template source and ignoring the configuration produced for deployment.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
43. Image layers and deleted sensitive files
Container images consist of filesystem layers. Deleting a file in a later layer can hide it from the final filesystem view without removing its bytes from an earlier layer. Inspect image history and layer contents when investigating secret exposure. Removing the file from future builds does not invalidate a credential already distributed.
Worked example: A credential is copied into an image and deleted in a later build step. It remains recoverable from an earlier layer, requiring artifact remediation and credential rotation.
Mistake to avoid: Checking only the final container filesystem for leaked build credentials.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
44. Approved registries and artifact access
Registry credentials authorize artifact access; an allowed-registry policy constrains artifact origin. These controls serve different purposes. Evaluate the resolved image reference, exact registry identity and every relevant container entry. An approved registry can still contain vulnerable or unauthorized artifacts, so origin restrictions should complement digest, signature and vulnerability requirements.
Worked example: A workload references an unapproved registry in an init container. Admission rejects it despite the main application's image coming from the approved registry.
Mistake to avoid: Using a loose text prefix that also matches a differently named registry.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
45. Image digests and mutable tags
A tag is a human-readable reference that can be reassigned; a digest identifies particular artifact content. Digest pinning strengthens the connection between reviewed and deployed artifacts. It does not prove publisher identity or security, and the pinned artifact still requires review and updates when its contents become unacceptable.
Worked example: The tag release moves to a different image after approval. Deploying the approved digest preserves the reviewed artifact despite the changed tag.
Mistake to avoid: Assuming a tag's familiar name guarantees that it still resolves to the previously inspected image.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
46. Artifact signatures and trusted signers
Signature verification establishes that an artifact was signed under a particular key or identity and has not changed relative to the signature. Trust requires deciding which signer is authorized and checking the applicable verification material. A valid signature from an unrelated signer does not satisfy an organization's release policy.
Worked example: An image has a valid signature, but its signer is a developer test identity rather than the approved release identity. Deployment validation rejects it.
Mistake to avoid: Accepting any cryptographically valid signature without enforcing signer identity.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
47. CI pipeline identities and secret boundaries
Build pipelines hold authority to read source, obtain dependencies and publish artifacts. Scope credentials to the task and protect them from untrusted build inputs. A contribution that can alter build code may execute with the job's privileges, so separate untrusted validation from trusted publishing and limit credential lifetime where supported.
Worked example: External contributions run tests without release credentials. Publishing occurs only in the separately authorized release job, keeping validation code outside the publishing trust boundary.
Mistake to avoid: Providing production publishing credentials to every job that processes contributed code.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
48. Build provenance and artifact linkage
Provenance describes how an artifact was produced, including relevant source, builder and inputs. Verification must establish the provenance's authenticity and connect its subject to the artifact being deployed. It complements signatures and SBOMs: each provides different evidence about identity, build origin or contents. Trust also depends on the builder and process.
Worked example: An attestation names the approved source revision but refers to another image digest. It cannot justify deployment of the candidate artifact.
Mistake to avoid: Accepting a convincing build description without checking its artifact digest and trusted origin.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
Monitoring, Logging, and Runtime Security
49. Behavioral baselines and contextual anomalies
Behavioral detection compares observed activity with a workload's expected role and context. An unusual process or destination is an investigation lead, not automatic proof of compromise. Baselines should account for approved maintenance and workload changes while retaining visibility into deviations that could indicate misuse.
Worked example: A normally quiet document service begins contacting an unrelated external endpoint. Its role offers no explanation, so the connection is investigated alongside process and deployment evidence.
Mistake to avoid: Declaring every unfamiliar event malicious without checking the workload's legitimate behavior.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
50. Process and syscall events as evidence
Runtime process and syscall events reveal actions that manifests cannot show, such as unexpected program execution or access attempts. Interpret them with process ancestry, user identity, container identity and workload purpose. A single event can be legitimate; a related sequence can provide stronger evidence of unexpected behavior.
Worked example: A shell starts inside a service container during an approved support session. Matching the process ancestry and API activity explains the event without suppressing all future shell detections.
Mistake to avoid: Treating the executable name alone as a complete threat classification.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
51. Attributing events to changing workloads
Pod names, addresses and node placement can change as workloads restart or reschedule. Reliable attribution needs stable event-time identifiers, such as pod UID and container identity, alongside namespace, service account and node information. Resolve ownership using the state relevant to the event rather than assuming current cluster state describes the past.
Worked example: An alert names an IP now assigned to another pod. Historical pod UID and container records identify the original workload correctly.
Mistake to avoid: Attributing an older event solely from the pod currently using its IP address.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
52. Kubernetes audit event meaning
Kubernetes audit events describe API activity, including the acting identity, requested operation, object reference and response information according to policy. Audit levels control how much request or response content is recorded. These records establish API interactions; they do not automatically describe every action performed inside a container or every network connection.
Worked example: An audit record shows an authorized account requesting pod execution. Runtime events are then needed to determine what processes actually ran in the container.
Mistake to avoid: Treating API audit logs as a complete transcript of container activity.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
53. Audit policy sensitivity and retention
More detailed audit logging can improve investigation while exposing sensitive request or response data and increasing volume. Audit rules are ordered, so the first matching rule determines handling. Choose appropriate detail for sensitive resources, protect storage and verify delivery and retention. A configured policy is ineffective if events are lost or inaccessible.
Worked example: Secret access is recorded at metadata level, preserving who accessed which object without intentionally collecting its request or response body.
Mistake to avoid: Placing a broad detailed rule first and expecting a later sensitive-resource rule to override it.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
54. Correlating API, runtime and network evidence
Different telemetry sources answer different questions. API logs describe control-plane requests, runtime events describe process behavior, and network records describe communication. Correlate timestamps and identities while considering clock differences and collection delays. Agreement across independent observations strengthens a conclusion; missing records may reflect telemetry gaps rather than absent activity.
Worked example: A deployment update, unexpected process execution and new outbound connection share the same workload identity. Together they establish a more useful sequence than any isolated alert.
Mistake to avoid: Assuming events with different collection timestamps necessarily occurred in that displayed order.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
55. Reconstructing attack progression
An investigation should distinguish initial access, execution, credential misuse, movement and impact when evidence supports those phases. Build a timeline from observed facts and label uncertain links explicitly. Avoid forcing every incident into every phase: identifying a confirmed first action and affected identities is more useful than inventing a complete narrative.
Worked example: Audit records show credential use before workload modification; runtime evidence then shows unexpected execution. That ordering supports a credential-driven deployment change as the observed entry path.
Mistake to avoid: Calling the earliest available log the proven beginning of the incident.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
56. Network threat detection under encryption
Network telemetry can reveal endpoints, connection patterns and traffic volume even when application payloads are encrypted, depending on collection capabilities. Unexpected destinations or communication between normally separate workloads warrant context-based investigation. Encryption protects contents but does not make every connection trustworthy, and flow records alone may not identify what data was transferred.
Worked example: A payment worker begins sustained outbound traffic to an unapproved destination. Flow evidence identifies the path; application and process evidence are needed to explain its contents.
Mistake to avoid: Claiming confirmed data theft from connection volume alone.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
57. Detecting threats on nodes and infrastructure
Cluster threats can involve nodes and infrastructure outside ordinary application pods. Inspect unexpected host processes, listening services, configuration changes and relevant administrative activity. Distinguish approved node agents from unexplained changes, and correlate findings with cluster activity. Pod-level visibility alone can miss host actions or changes affecting many workloads.
Worked example: A new host listener appears without an approved maintenance change. Node process and access records help identify its origin and the workloads potentially exposed.
Mistake to avoid: Limiting investigation to application container logs when the suspicious behavior originates on a node.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
58. Distinguishing account misuse from application misuse
Threats can use valid identities and permitted application functions. API credential misuse, unauthorized user actions and abuse through an application may produce different evidence. Assess whether the suspicious action reached the Kubernetes API, the application interface or the underlying host. An absence of unusual Kubernetes API calls does not establish that application data is safe.
Worked example: Customer records are accessed through a stolen application session without Kubernetes API activity. Application authentication and access logs provide the relevant investigation path.
Mistake to avoid: Using a clean Kubernetes audit trail to rule out application-level compromise.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
59. Runtime immutability and writable exceptions
A read-only root filesystem limits changes to the container's image filesystem but does not make every mounted volume read-only or prevent execution and network activity. Identify necessary writable paths and provide narrowly scoped storage for them. Runtime immutability complements identity restrictions, confinement and monitoring rather than replacing those controls.
Worked example: A service uses a read-only root filesystem with a dedicated writable temporary volume. It can create temporary files without modifying its installed application.
Mistake to avoid: Assuming readOnlyRootFilesystem also protects every mounted volume from writes.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
60. Containment while preserving evidence
Containment limits continuing access or communication while evidence preservation supports investigation. Select actions according to the affected identity, workload and infrastructure, following the environment's response procedure. Restarting or replacing a container can erase useful transient evidence; leaving it unrestricted can permit continued harm. Establish the exposure and preservation needs before choosing the intervention.
Worked example: Unexpected credential use is confirmed. The response restricts that identity's access and preserves relevant audit and runtime records before rebuilding the affected workload.
Mistake to avoid: Deleting suspicious workloads immediately and losing the evidence needed to determine their scope.
Source reference: 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
Official sources
Exam identity verified:
- 認定Kubernetesセキュリティスペシャリスト (CKS-JP) - Linux Foundation - Education
- Certified Kubernetes Security Specialist (CKS) | CNCF