Kubernetes Security Best Practices and Zero Trust Access

Enterprises and governments around the world recognize that adopting a Zero Trust security model represents the most efficient and effective way to protect assets within today’s threat landscape.

However, there’s often a gap between knowing what you want to do and understanding how to do it. So, while organizations want to extend core Zero Trust principles to ensure secure access to all resource access regardless of where they reside … it’s a multi-step Kubernetes security best practices journey to achieve least privilege strategy, enforce access control and inspect and log all traffic in hybrid environments.

And nowhere is the challenge greater than in the cloud, especially when it comes to containers, clusters and Kubernetes security due to the unique complexities of these dynamic environments and a scarcity of the skills required to execute Kubernetes security best practices.

Cloud and Kubernetes security demands a different approach

In the context of securing the cloud, IT professionals have many concerns, including:

• Maintaining consistent security across traditional and cloud-native workloads
• The increasing complexity created by introducing additional Kubernetes security controls
• Lack of support for cloud-native environments from current security solutions
• Protecting a new attack surface
• Preventing attackers from using cloud workloads as part of a kill chain
• Streamlining DevSecOps to ensure that developers don’t get ahead of security policies

Unfortunately, current network security concepts don’t work well in the cloud, especially when it comes to Kubernetes security best practices. For this reason, most cloud environments come with built-in concepts like security groups and container service meshes that allow automatic network security provisioning as part of service deployments.

These methodologies might work well for simple applications, but they lose their power as soon as you make a connection to or from various external resources, regions, clouds or technology stacks. For example, there is no interoperability between different cloud vendors’ security groups and tools.

The fallback options—like reverting to network ACLs to filter IP addresses over intercloud connectivity (SD-WAN/IPSEC/MPLS)—are impractical when ephemeral workloads are used that change IP addresses constantly or when multiple services share the same cluster IP.

Kubernetes security presents unique challenges

Kubernetes is a driving force for DevOps, DevSecOps and cloud-native workloads, and all major cloud platforms (Google, AWS and Azure) now offer a Kubernetes service.

Built as an open-source platform, Kubernetes provides the container orchestration engine for microservice-based software architectures. However, while Kubernetes enables the speed, agility and application performance to help drive enterprise digital transformation, it also comes with a unique set of security challenges that have real-world consequences. For example, Red Hat’s 2021 State of Kubernetes Security report highlighted that more than half of survey respondents delayed deploying Kubernetes applications into production due to security concerns, and almost all respondents experienced at least one security incident in their Kubernetes environments in the last year.

So, although it’s safe to say that Kubernetes is driving digital transformation, Kubernetes security requires specific attention.

Unfortunately, the main Kubernetes security webpage offers little more than a starting point. It outlines four layers of security—cloud, cluster, container and code—but, of the four, only the cluster is considered to be within the scope of Kubernetes security. Moreover, the direction provided is fairly vague—even within the Securing a Cluster webpage—making it very difficult for non-experts to implement anything beyond rudimentary defenses, let alone a full Zero Trust model.

Implementing Zero Trust to enhance Kubernetes security

In stark contrast to Kubernetes’ trusting defaults, the Zero Trust security paradigm does away with the notion of a perimeter and assumes that no user, network, system or service should be trusted.

Implementing Zero Trust for Kubernetes security requires leveraging hooks that control authentication, authorization, admission control, plus logging and auditing to control access to each cluster’s API server. Employing these hooks, an enterprise can increase Kubernetes security by applying Zero Trust principles to precisely control:

1. User-to-service access
2. Service-to-service access

Kubernetes security hurdles for user-to-service connections

Developers, operators, administrators and other users—including third parties such as partners and contractors—need secure and convenient access to Kubernetes environments. Importantly, though, the specific access needs—in terms of who needs access to what services, and with what privileges—vary from role to role, and even from user to user.

Complicating matters, these users will access the Kubernetes environments from a diverse mix of devices or locations, and many enterprises have multiple Kubernetes environments corresponding to different stages of the DevOps pipeline: development, quality assurance, staging, production, etc.

Moreover, the clusters that make up these environments may be spread across a combination of public cloud providers, private clouds, on-premises data centers and edge locations.

Unfortunately, Kubernetes’ security options don’t meet enterprise-level security requirements, so the burden of securing access falls to the organization—but the complexity and dynamism inherent to user-to-service access renders traditional tools and manual administration completely impractical.

Kubernetes security hurdles for service-to-service access

In a simple Kubernetes environment, containers and pods need to communicate with each other. In many (perhaps most) Kubernetes deployments, services will also need to communicate with services or traditional resources located elsewhere.

In either scenario, permissive access policies will allow intruders to move laterally, potentially gaining access to sensitive data and disrupting operations.

Unfortunately, in its default state, Kubernetes is very trusting—within each cluster, any container can communicate directly with any other container—and while Kubernetes network policies allow admins to take the first step towards a Zero Trust approach by configuring default deny rules to incoming and outbound traffic, much more is needed to secure service-to-service communication.

A robust Zero Trust access solution for Kubernetes security: Appgate SDP

Even if an organization has an abundance of cloud-native expertise, building scalable systems to implement Zero Trust Kubernetes security (i.e., by leveraging the API hooks and integrating into existing solutions that provide IAM, posture management, etc.) is a daunting project. For most enterprises, implementing a third-party solution is a faster, more secure and more cost-effective option.

Appgate SDP, an industry-leading Zero Trust Network Access (ZTNA) solution, unifies user-to-service and service-to-service access for Kubernetes workloads. In doing so, it accelerates digital transformation by providing least privilege access and enabling granular, dynamic Kubernetes security—all in a single policy model that reduces operational and management overhead.

SDP Gateways secure ingress into each Kubernetes cluster, strictly controlling access from users and services (i.e., from outside the cluster), and a sidecar SDP client secures egress to resources outside the cluster (e.g., a database, microservice, etc.), no matter the external resource’s location. In tandem, these two components enable secure:

1. DevOps or admin access to Kubernetes resources like the UI or kubctl CLI
2. Workforce access to web-based microservice applications
3. Pod-level egress access from containers to resources that live outside the cluster
4. Temporary, on-demand access for private air gap Kubernetes deployments for patches, code updates and administration

By protecting microservices, enforcing granular, secure access to and from Kubernetes environments and building security into CI/ CD pipelines, Appgate SDP allows enterprises to extend Zero Trust Kubernetes security across their complete array of cloud deployments while streamlining security into their DevSecOps pipeline for faster agility and consistent safeguards.

To learn more, download the Zero Trust for Kubernetes security datasheet or watch the Zero Trust access for Kubernetes security best practices video.

Additional Kubernetes security and secure cloud resources

• Blog: Secure DevOps Workloads in the Cloud
• Zero Trust Thirty podcast episode: Crawl, Walk, Run: Zero Trust for Cloud
• Solution brief: Securing Cloud Access
• Use case: Zero Trust for Cloud