Practice Labs : Certified Kubernetes Security Specialist CKS

What are Network Policies in Kubernetes?

Network Policies are a mechanism for controlling network traffic flow in Kubernetes clusters. They allow you to define which of your Pods are allowed to exchange network traffic. You should use them in your clusters to prevent apps from reaching each other over the network, which will help limit the damage if one of your apps is compromised.

Each Network Policy you create targets a group of Pods and sets the Ingress (incoming) and Egress (outgoing) network endpoints those Pods can communicate with.

There are three different ways to identify target endpoints:

• Specific Pods (Pods matching a label are allowed)

• Specific Namespaces (all Pods in the namespace are allowed)

• IP address blocks (endpoints with an IP address in the block are allowed)

Purpose of Network Policies:

• Isolation: Network policies enable you to create logical network boundaries within your Kubernetes cluster, allowing you to isolate workloads and control communication between different parts of your application.

• Security: By defining rules for traffic flow, network policies help enforce security policies and reduce the attack surface within your cluster. They allow you to restrict communication to only authorized pods and services, helping to prevent unauthorized access and potential security breaches.

  
  

Kubernetes Network Policy use cases

Using Network Policies is a best practice for a secure Kubernetes configuration. They prevent Pod network access from being unnecessarily broad, such as in the following scenarios:

• Ensuring a database can only be accessed by the app it’s part of: Databases running in Kubernetes are often intended to be solely accessed by other in-cluster Pods, such as the Pods that run your app’s backend. Network Policies allow you to enforce this constraint, preventing other apps from communicating with your database server.

• Isolating Pods from your cluster’s network: Some sensitive Pods might not need to accept any inbound traffic from other Pods in your cluster. Using a Network Policy to block all Ingress traffic to them will tighten your workload’s security.

• Allow specific apps or namespaces to communicate with each other: Kubernetes namespaces are the primary mechanism for separating objects associated with different apps, teams, and environments. You can use Network Policies to network-isolate these resources and achieve stronger multi-tenancy.

  
  

Understanding Network Policies

Network Policies are implemented using Kubernetes resources that define how pods are allowed to communicate with each other and other network endpoints. They use labels to select pods and define rules for ingress (incoming) and egress (outgoing) traffic.

Key Concepts:

• Pod Selector: Selects the group of pods to which the policy applies.

• Ingress Rules: Define allowed incoming traffic.

• Egress Rules: Define allowed outgoing traffic.

• Policy Types: Can be either ingress, egress, or both.

What is Anonymous Access in Kubernetes?

In Kubernetes, anonymous access refers to the ability to access the Kubernetes API server without any form of authentication. When anonymous access is enabled, any request that does not include authentication credentials is treated as an anonymous request. These anonymous requests are assigned a user identity of system:anonymous and belong to the group system:unauthenticated.

What is CA, Cert, and Key in Kubernetes Authentication?

CA (Certificate Authority):

A Certificate Authority (CA) is an entity responsible for issuing and verifying digital certificates. In the context of Kubernetes, the CA is used to sign certificates for the various components of the cluster, ensuring secure communication between them. The CA certificate is distributed to the Kubernetes components to establish a chain of trust.

Client Certificate:

A Client certificate in Kubernetes is a digital document used to prove the identity of a user or a component within the cluster. Certificates are typically issued by the CA and include the public key, identity information, and the CA's digital signature. Certificates are used in mutual TLS (mTLS) authentication to ensure secure communication between the Kubernetes components, such as the API server, kubelet, and etcd.

Client Key:

The Client key refers to the private key associated with a certificate. The private key is a secret piece of data that should be kept secure and never shared. It is used with the certificate to authenticate and encrypt communication. When a component presents its certificate during a TLS handshake, it uses the corresponding private key to prove its identity.

What is Role-Based Access Control (RBAC) in Kubernetes?

Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In Kubernetes, RBAC is a key security feature that controls who can access specific resources and operations within a cluster.

Key concepts in RBAC:

• Roles

  • Role: Defines a set of permissions within a specific namespace. Roles are namespace scoped.

  • ClusterRole: Defines a set of permissions that can be applied cluster-wide or within specific namespaces. ClusterRoles are cluster scoped.

• RoleBindings

  • RoleBinding: Associates a Role with one or more users, groups, or service accounts within a specific namespace.

  • ClusterRoleBinding: Associates a ClusterRole with one or more users, groups, or service accounts cluster wide.

• Users and Groups

  • User: Represents an individual identity.

  • Group: Represents a collection of users.

  • Service Account: Represents an identity for processes running in pods.

What is a Service Account?

Service Accounts are a critical concept in Kubernetes that allows applications, running as containers, to interact with the Kubernetes API and other resources within the cluster. Unlike user accounts, which are tied to individuals, service accounts are meant for applications, processes, and system components. Each service account has specific permissions and roles associated with it, defining what actions it can perform within the cluster.

Potential Risks of Misusing Service Accounts:

• Over-privileged Service Accounts: If a service account is granted more permissions than necessary, it can lead to potential security vulnerabilities. For instance, an application running with a service account that has admin-level privileges can be exploited to perform harmful actions, such as deleting resources or modifying sensitive configurations.

• Unauthorized Access: Service accounts are used to authenticate applications to the Kubernetes API. If a service account's credentials are leaked or exposed, an attacker could use them to gain unauthorized access to the cluster and manipulate resources.

• Privilege Escalation: If an attacker gains control over a pod that runs with an over-privileged service account, they can escalate their privileges within the cluster, potentially gaining control over other resources or even the entire cluster.

Best Practices for Managing Service Accounts:

• Principle of Least Privilege: Always assign the minimum permissions necessary for the service account to perform its intended tasks. This limits the potential damage that can be done if the service account is compromised.

• Avoid Using Default Service Accounts: Kubernetes creates a default service account in every namespace. Avoid using this account for your applications, as it might have broader permissions than required. Instead, create specific service accounts with tailored permissions.

• Use Role-Based Access Control (RBAC): Implement RBAC to define and enforce permissions for service accounts. By creating specific roles and binding them to service accounts, you can ensure that each account only has access to the resources and actions it needs.

Why Upgrade Your Kubernetes Cluster?

Upgrading a Kubernetes cluster is a critical task for maintaining the security, stability, and performance of your Kubernetes environment. Regular upgrades ensure that you benefit from the latest features, improvements, and security patches provided by the Kubernetes community. This theory section will cover the key concepts and considerations that you need to understand before performing a Kubernetes upgrade.

• Security Enhancements: Kubernetes releases often include patches for security vulnerabilities. Upgrading ensures your cluster is protected against known security threats.

• New Features and Improvements: New Kubernetes versions introduce new features, enhancements to existing features, and performance improvements. Upgrading allows you to take advantage of these benefits.

• Compatibility and Support: Kubernetes has a defined support cycle, and older versions eventually reach end-of-life. Upgrading ensures that you remain within the supported versions and receive updates and bug fixes.

• Bug Fixes: Each new release includes fixes for bugs and issues found in previous versions. Upgrading helps maintain a stable and reliable cluster.

Understanding Kubernetes Versions:

Kubernetes versions follow the pattern vX.Y.Z, where:

1. X is the major version.

2. Y is the minor version.

3. Z is the patch version.

Upgrades can be:

• Patch Upgrades: Focused on bug fixes and minor improvements, with no major changes to APIs.

• Minor Upgrades: Introduce new features and enhancements, but may also include API deprecations and changes.

• Major Upgrades: Rare and involve significant changes that may not be backward-compatible.

Exploring Kernel Hardening Tools

AppArmor

AppArmor is a Mandatory Access Control (MAC) system that restricts programs to a limited set of resources. It is implemented as a Linux Security Module (LSM) and is designed to prevent both known and unknown application flaws from being exploited. AppArmor works by enforcing a set of rules, called profiles, that define what system resources an application can access and with what privileges.

Key Features of AppArmor:

• Mandatory Access Control (MAC): AppArmor supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control.

• Path-Based: AppArmor is path-based, meaning it uses file paths to determine access control.

• Profiles: AppArmor uses profiles that are loaded into the kernel at boot time. These profiles can be in enforcement or complain mode.

seccomp

seccomp (Secure Computing with the seccomp BPF) is a Linux kernel feature that allows a process to specify a filter for the system calls it can make. This filter is used to restrict the system calls that can be made by a process, thereby enhancing security.

Key Features of seccomp:

• System Call Filtering: seccomp allows processes to specify a filter for the system calls they can make.

• BPF (Berkeley Packet Filter): seccomp uses BPF to filter system calls.

• Flexibility: seccomp can be used to restrict system calls based on specific requirements.

Securing Images using Trivy

What is Trivy?

Trivy is an open-source vulnerability scanner designed to identify security vulnerabilities and misconfigurations in various components of your software development lifecycle. It is particularly focused on container images but also supports scanning other artifacts such as file systems, Git repositories, and Kubernetes clusters. Developed by Aqua Security, Trivy is a powerful tool for ensuring the security of applications from development through to production.

Key Features of Trivy:

• Container Image Scanning: Trivy can scan container images to detect vulnerabilities in the packages and dependencies used within the image. This helps ensure that the images you deploy do not contain known security flaws.

• File System Scanning: It can scan the file system of a host to detect vulnerabilities in installed software packages and identify any security misconfigurations.

• Infrastructure as Code (IaC) Scanning: Trivy can analyze IaC templates such as Terraform, Kubernetes YAML files, and AWS CloudFormation templates to detect security misconfigurations and adherence to best practices.

What is Immutability?

In a containerized environment, immutability refers to the principle that containers, once created and deployed, should not be modified. This ensures that the application behaves predictably, reduces the risk of security vulnerabilities, and simplifies debugging and troubleshooting. Immutability is a key concept in modern DevOps practices and is fundamental to the operational integrity and security of containerized applications.

Benefits of Immutability:

1. Predictable Deployments: Immutable containers guarantee that what you deploy is exactly what you tested, ensuring consistency across development, testing, and production environments.

2. Simplified Debugging: Since the container’s state does not change, reproducing and diagnosing issues becomes straightforward. You can be sure that the deployed container is identical to the one you tested.

3. Enhanced Security: By making the container filesystem read-only, you prevent unauthorized changes and reduce the attack surface. This limits the ability of an attacker to modify the application or system binaries.

4. Easier Rollbacks: If an issue is discovered with a new deployment, you can easily roll back to a previous version by redeploying the prior immutable image.

Implementing Immutability:

• Container Images: Build images that contain everything the application needs to run. Do not rely on pulling dependencies or configurations at runtime.

• Read-Only Filesystems: Configure containers to use read-only filesystems. This prevents any changes to the file system after the container has started.

• Kubernetes Policies: Use Kubernetes security contexts and policies to enforce immutability at the orchestration level. This includes using Pod Security Policies (PSP) or the newer Pod Security Standards (PSS).

Auditing assists in maintaining compliance. It helps by providing the ability to retrieve certain sequences of events a user has initiated. This ability to retrieve the historical records of changes made to the cluster provides deep insights into strengthening the regulatory framework in the organization.

What are the stages during Audit logging

The kube-apiserver allows us to capture the logs at various stages of a request sent to it. This includes the events at the metadata stage, request, and response bodies as well. Kubernetes allows us to define the stages which we intend to capture. The following are the allowed stages in the Kubernetes audit logging framework:

• RequestReceived: As the name suggests, this stage captures the generated events as soon as the audit handler receives the request.

• ResponseStarted: In this stage, collects the events once the response headers are sent, but just before the response body is sent.

• ResponseComplete: This stage collects the events after the response body is sent completely.

• Panic: Events collected whenever the apiserever panics.

There are lots of calls made to the API server, and we need a mechanism to filter out the events based on our requirements. Kubernetes auditing provides yet another feature for this very reason — the level field in the policy configuration.

What are the levels at which Auditing needs to happen

The level field in the rules list defines what properties of an event are recorded. An important aspect of audit logging in Kubernetes is, whenever an event is processed it is matched against the rules defined in the config file in order. The first rule sets the audit level of logging the event. Kubernetes provides the following audit levels while defining the audit configuration.

• None: This disables logging of any event that matches the rule.

• Metadata: Logs request metadata (requesting user/userGroup, timestamp, resource/subresource, verb, status, etc.) but not request or response bodies.

• Request: This level records the event metadata and request body but does not log the response body.

• RequestResponse: It is more verbose among all the levels as this level logs the Metadata, request, and response bodies.