Kubernetes for Beginners – A Step-by-Step Guide

This blog was originally published by Vulcan Cyber here.

Written by Natalie Kriheli, Vulcan Cyber.

For beginners, Kubernetes can seem pretty daunting. It offers a feature-rich, flexible, and extensible platform, but the downside is that Kubernetes security can be quite challenging. Any misconfigurations in Kubernetes can potentially expose your application data and allow malicious actors to compromise its services.

While there exist several means for protecting against common threats such as unauthorized access, denial of service attacks, and malware propagation, they do little to prevent more sophisticated attacks like credential theft, privilege escalation, and lateral movement. An effective Kubernetes security strategy must cover all phases of the container and application lifecycle. This requires a thorough and multifaceted approach.

Whether you’re running on-premises or using managed solutions such as AWS EKS, Azure AKS, or GCP GKE, Kubernetes offers various native security mechanisms and tools to address security concerns. However, these often fall short in today’s rapidly changing security landscape. This article explores security fundamentals and best practices your organization can leverage to implement robust security across your Kubernetes clusters.

Kubernetes Security Fundamentals

Securing Kubernetes clusters has long been a challenge for security teams due to the need to specify which features should be activated by default. Managing cluster component configurations, too, is an arduous task, which can further complicate the delivery and automation of secure workloads. In addition to this, for modern businesses that leverage multiple cloud platforms to deploy workloads, the challenges of multi-cloud security are often unknown and unique.

While Kubernetes offers a number of security features out of the box, the platform does not include all the necessary tools required to build secure microservices architectures. As such, developers must implement certain best practices when building services using containers. These guidelines help protect against common vulnerabilities such as insecure configuration management, weak authentication mechanisms, poor logging, and misconfigured firewalls.

Cloud security basics

Cloud-native security practices leverage a defense-in-depth approach. This allows security teams to use a layered system to augment controls and establish virtual borders across your organization’s tech stack. Within this framework, each layer in the security model is encompassed by the next outermost layer, which acts as defense in the event of a security breach.

Cloud-native security is based on four fundamental principles:

1. Application security

Also referred to as code security, this principle addresses attack surfaces in the source code of microservices. While securing source code lies outside the scope of a Kubernetes cluster, recommendations for protecting source code for applications running in the orchestrator’s environment include:

• Encrypting traffic between applications using TLS
• Only exposing ports that are crucial for metric collection and communication
• Always scanning third-party libraries for vulnerabilities
• Using static code analysis (SCA) tools for secure coding practices
• Using penetration tests and threat modelling tools to detect attack surfaces before they are exploited

2. Container security

While containers are deployed and run in Kubernetes, they are built and created in container runtimes, such as Docker, Containerd, or CRI-O. A container runtime layer exposes various security vulnerabilities. These must be mitigated in order to ensure robust security across the entire ecosystem.

Best practices for securing container runtimes include:

• Enforcing image-signing policies: Outdated container images are often more prone to becoming targets of successful attacks. To mitigate this, it is important to enforce image-signing policies, which establish a trust system for container images and repositories.

• Principle of least privilege: By default, the defined security policy should grant only the minimum user privileges required for managing containers; privilege level should be escalated only if absolutely necessary.

• Container isolation: Security policies should limit use of container runtime engines only to those that include specific classes for container isolation.

3. Cluster security

Cluster security addresses secure configuration of cluster components and securing applications hosted within the cluster. The main cluster components to look out for are the ETCD data store and the API Server. Kubernetes documentation features detailed guidelines for configuring and controlling access of cluster services.

4. Cloud seurity

This principle involves securing all the components and services of the infrastructure that collectively support the cloud instance. While most of the security responsibilities lie with the cloud service provider—whether AWS, Azure, or GCP—as the customer, your organization must also periodically configure and monitor these services to fit your use case. Automation tools to assess misconfigurations help ensure open vulnerabilities are mitigated and thus improve the platform’s security posture.

How Kubernetes implements security

While securing your workloads is the primary goal, it is also critical to implement security controls throughout the container lifecycle. This involves a combination of approaches for each phase of the application lifecycle, as discussed in this section.

Authentication

Authentication is the process of verifying a user’s identity to ensure only recognized accounts can access a system. Kubernetes uses Service Accounts to manage identities of all users/services allowed to interact with the API Server. Security teams can authenticate HTTP requests to the API server using a number of methods, including:

• Client certificates (TLS encryption)
• Bearer tokens
• Authenticating tokens
• HTTP basic authentication

Authorization

Once a user has been authenticated into a system, the authorization process determines the user’s permissions and level of access to resources. Security teams can create a set of policies used to authorize access requests using any, all, or a combination of the following authorization strategies:

• Role-based access control (RBAC)
• Attribute-based access control (ABAC)
• Node authorization
• Webhook

Image security

Both private and public image registries often contain vulnerabilities. To ensure such vulnerabilities do not make it to production, Kubernetes relies on admission controllers to ensure that only images with strict security controls are deployed. Apart from leveraging admission controllers, it is also important to adopt the following best practices to administer robust image security:

• Build security into the CI/CD pipeline.
• Vet third-party image registries.
• Use minimal base images.
• Opt for private, internal registries.

Network policies

By default, pods accept traffic from any entity and follow non-isolation. Network policies enable teams to specify how pods communicate with other cluster objects and allow traffic flow control at the IP/Port Address level. These policies provide a mechanism for specifying which ports or protocols a pod should be able to use when communicating with other pods within the same namespace. To restrict pods from accepting traffic from any internal/external entities, Kubernetes network policies are used to maintain pod isolation and specify network endpoints the pod can accept traffic from.

Leverage Security Resources: Secrets & ConfigMaps

Secrets and ConfigMaps are used to inject configuration data into containers on startup. Secrets are base64 encoded and are used to store sensitive information, such as credentials and authentication tokens. ConfigMaps, on the other hand, are not base64 encoded and are mostly used to save non-sensitive configuration data, such as environment variables and config files.

Securing Kubernetes Clusters

There are various frameworks and best practices for securing a Kubernetes cluster. Discussed below are some of the more popular compliance frameworks offering guidelines on how to secure your Kubernetes cluster.

Kubernetes security & compliance frameworks

Kubernetes security frameworks were developed to provide standardized guidelines for managing security risks based on real-world scenarios. Some of the more prominent Kubernetes security frameworks are discussed as follows.

CIS Kubernetes Benchmark

The Center for Internet Security (CIS) Kubernetes Benchmark enables security teams to harden Kubernetes clusters by providing guidance on how to secure configuration of cluster components. CIS also recommends tools to help your organization assess its current security state and identify areas for improvement. This aids in enabling cluster-wide vulnerability scanning and standardizing efforts to minimize cluster attack surfaces.

Kubernetes MITRE ATT&CK® framework

The MITRE ATT&CK framework for Kubernetes provides a template for threat modelling through the documentation of various tools, tactics, and techniques used for attacks. Based on real-world observations, your organization can leverage the framework to simulate the behavior of an attacker and identify susceptible entry points.

PCI-DSS compliance for containers

The PCI-DSS compliance framework outlines best practices to protect cardholder data in containerized applications. PCI-DSS is a universally recognized standard allowing for the assessment of your applications and the security posture of the underlying platform, thus enhancing privacy and protecting confidential data.

NIST Application Container Security framework

The NIST Application Container Security Guide features a Risk Management Framework for hardening containerized environments and securing containers. The document outlines various security concerns associated with container orchestration and recommends remediation practices for hardened security.

8 Kubernetes security best practices

Securing Kubernetes workloads requires a comprehensive approach to administering security across all layers of the ecosystem. Best practices to secure Kubernetes workloads therefore focus on addressing multiple challenges of platform dependencies and architectural vulnerabilities, as discussed in this section.

1. Use the latest Kubernetes version

As a well-managed CNCF project, Kubernetes is constantly being updated, as vulnerabilities are discovered and patched all the time. Using one of the recent major Kubernetes versions is a must for organizations in order to take advantage of new security features and ensure workloads are not susceptible to recent attack trends.

2. Use role-based access control

RBAC simplifies access control by assigning privileges according to your organizational structure and defined roles. Not only is RBAC recommended for user-level access; but also for administering cluster-wide and namespace-specific permissions.

3. Isolate resources using namespaces

Namespaces are virtual clusters that help organize resources through access control restrictions, network policies, and other crucial security controls. To ensure resources are not susceptible to attacks, namespaces should be used to establish boundaries that make it easier to apply security controls.

4. Separate sensitive workloads

As a best practice, sensitive applications should be run on a dedicated set of nodes to limit the impact of successful attacks. You’ll also want to make sure these nodes are isolated from public-facing services so that even if one node is compromised, the attacker is unable to escalate privileges and gain access to other nodes.

5. Secure ETCD

Due to their importance in the Kubernetes ecosystem, ETCD servers are a common target of attack vectors. It is therefore important to ensure that the ETCD service has adequate security measures in place. All services should be secured with strong authentication mechanisms such as TLS/SSL certificates or using mutual authentication between client and server.

6. Use cluster-wide pod security policies

Your organization should define robust policies to outline how workloads should be run in the cluster. Ensure that your network configuration allows traffic only where necessary, and disable unnecessary ports and protocols that may open susceptible entry points.

7. Keep nodes secure

It’s important to minimize administrative access to nodes, while also controlling network access to ports used by the Kubelet service. It is also recommended to use iptables rules for ingress and egress traffic on the cluster’s public IP address as well as any other external services or applications that may need to connect to the cluster. This will help prevent malicious users from accessing nodes via SSH/RDP connections.

8. Activate audit logging

Audit logs are a set of records that contain information about the events and actions performed by an entity or process on Kubernetes cluster resources. The event data can be used for troubleshooting purposes as well as auditing activities such as security audits. Audit log entries also provide details regarding the identity of the user who initiated each action. It is recommended to use audit logs and monitor them to correlate activity with users across your organization’s network boundaries.

Summary

Despite its quick adoption and growing popularity, Kubernetes presents many challenges—prime among them security. One survey found that over 74% of software companies reported they were already running their production workloads using a Kubernetes distribution. According to another survey, 55% of organizations delay production rollouts, citing security as one of the primary concerns.

Provided your platform is correctly configured, Kubernetes provides an excellent foundation for building highly available and scalable containerized apps. By following best practices and frameworks, you’ll be able to implement robust security controls for your Kubernetes clusters.