Zero-Trust for Kubernetes

Zero-trust is a new security paradigm that is adopted by the world’s biggest and most technically advanced organizations, including Google, Microsoft, and Amazon Web Services (AWS). It is being applied to virtually every technology platform and infrastructure, and Kubernetes is no exception. If you are running Kubernetes in your organization, you need to understand how Kubernetes security is impacted by zero-trust and what you need to do to ensure your Kubernetes deployment is zero-trust compliant.

What is Zero-Trust?

Zero-trust refers to a set of policies, architectures, and frameworks that follow the principle of always verifying, never trusting. The zero-trust model treats all users and resources as potentially suspicious, continuously requiring the validation of entities for each activity and each computing session. 

Zero-trust is a distributed, granular security regime that grants access according to details such as the data, users, systems and session scenarios involved.

Zero-trust security incorporates three basic principles:

  • Continually verify and validate the identity of each person connecting to your organization.
  • Continually verify and validate each asset connecting to your organization—this includes networks, systems, applications and devices.
  • Monitor and control access to each user, asset and resource.

The Importance of a Zero-Trust Network

Corporate networks and distributed applications continuously evolve and grow in complexity, with new threats emerging to exploit them. 

A security perimeter only serves as the first line of defense protecting your internal networks, but you cannot rely on it alone to protect your data and infrastructure. By combining different security methods, you can increase your security posture. A zero-trust network is one crucial aspect of your overall security strategy, focusing on internal application traffic. 

Traditionally, many organizations assumed that all traffic originating within their firewalled networks was safe—zero-trust assumes the opposite, with all network connections considered untrustworthy unless proven otherwise. Zero-trust ensures that all applications require strong authentication and secure credentials.  

Without zero-trust, applications have to perform their own authentication and authorization (if any). Organizations often leave internal network connections, including those for sensitive applications, unencrypted. Many organizations use lax internal security structures and reuse weak passwords across users and applications. 

Malicious actors can infiltrate your system via direct hacks, social engineering techniques or vulnerabilities such as a hole in the network firewall. Once inside the network, an attacker could leverage the implicit trust of a non-zero-trust network. In an unprotected system, infiltrators can sniff plaintext network packets to discover passwords to critical applications and databases, gain equipment control, exfiltrate data and more. 

Zero-trust is increasingly at the center of production environment security. A zero-trust approach treats even the network infrastructure as untrustworthy. There is no single ‘right’ way to implement a zero-trust framework, and you can use various technologies to achieve it. Zero-trust is simply a set of goals and principles—the technical specifics are up to you. 

Applying Zero-Trust Principles to Your Kubernetes Deployments

The Kubernetes control plane for every cluster has the Kubernetes API Server at its core. API calls enable queries that manipulate the state of each Kubernetes object including pods, namespaces and config maps. Controlling API access is thus key to controlling and securing Kubernetes access in a zero-trust model. To secure, you first have to protect incoming and outgoing API server traffic using transport layer security (TLS).

With transport secured, Kubernetes provides the hooks required to implement zero-trust and control API server access across all Kubernetes clusters. There are four main types of hooks: Authentication, authorization, admission control and logging.

Authentication

Kubernetes zero-trust requires the authentication of every user and service account before allowing the execution of an API call. Several plugins and security modules allow the Kubernetes platform to work with your chosen authentication system. An important best practice is to use multi-factor authentication (MFA), combining two or more of the following:

  • Client certificates
  • Bearer tokens
  • OpenID Connect (OIDC) tokens
  • HTTP basic authentication
  • Authentication proxies
  • Webhook token authentication

Authorization

You shouldn’t allow all users or service accounts accessing your Kubernetes cluster to perform any possible action. Kubernetes zero-trust authorizes requests only when the authenticated user has the appropriate permissions. Every request includes the requester’s username, the requested action and relevant objects.

Kubernetes allows you to implement authorization using various methodologies, such as:

  • Attribute-based access control (ABAC)—this method provides dynamic access authorization based on various attributes relating to the environment, user and resource.
  • Role-based access control (RBAC)—this method provides access authorization based on the user’s role within the organization (i.e., developer, security, admin, etc.).

RBAC is the more popular option because it is easier to manage and offers a sufficient level of granularity for most use cases. ABAC provides higher granularity but can be time-consuming to configure and manage and troubleshooting may be more difficult in the event of an error. Learn more about the differences between RBAC and ABAC here.

Admission Control

You can refine your Kubernetes zero-trust strategy by implementing business logic. An admission controller allows you to manage requests to perform actions on Kubernetes objects, including creating, modifying, deleting and connecting to them. There may be multiple admission controllers in a system, and if one controller rejects a request, the system rejects the request immediately.

You can implement actions and enforce policies using various built-in admission controllers. A dynamic admission controller lets you modify requests in real-time to meet your access control rules. An example of a controller is the ResourceQuota, which observes incoming requests and verifies that they comply with the constraints specified in the ResourceQuota namespace object. 

Logging 

Auditing and logging are essential to maintaining security. You can leverage Kubernetes auditing capabilities to keep track of all actions performed in a cluster, whether they are actions performed by applications, users or the control plane. You can choose where to log audited events—the log backend can write events to the local filesystem of a cluster and the webhook backend can forward audited events to a third-party logging system.

Basic Steps for Implementing Zero-trust in a Kubernetes Environment

Organizations are increasingly using containerized cloud deployments for production environments. Containers are easy to use, allowing you to deploy secure, streamlined infrastructure. Kubernetes is a leading container orchestration system that provides scalability, flexibility and automation. However, while the Kubernetes platform allows you to manage secrets, it does not automatically apply a zero-trust approach. 

To implement zero-trust in Kubernetes, you should follow these steps:

  • Identify all resources in your deployment.
  • Authenticate all requests.
  • Apply the principles of least-privilege and just-in-time to authenticated workloads.
  • Remove privileges after the completion of each.
  • Continuously monitor, audit and control all activity.

Applying these requirements to every user, program and access request allows you to enhance your security posture in Kubernetes. Maintaining control of access to pods helps prevent both external and internal attacks. 

To leverage Kubernetes in a zero-trust environment, you can use the secure production identity framework for everyone (SPIFFE), which provides authentication capabilities for workloads. Kubernetes also offers native tools that allow you to monitor your network and automate the creation of rules and policies.

Conclusion

In this article, I explained the basics of zero-trust and how you can use the zero-trust model to improve security in a Kubernetes environment. In particular, I covered four ways to implement zero-trust in a Kubernetes cluster:

  1. Authentication—Use Kubernetes mechanisms like HTTP basic auth, bearer tokens and OIDC tokens to ensure all cluster communication is authenticated.
  2. Authorization—Leverage ABAC or RBAC to authorize all operations within the cluster, following the least-privilege principle.
  3. Admission control—Create Kubernetes admission controllers that can be used to evaluate requests to create, modify or delete Kubernetes objects.
  4. Logging and auditing—Ensure all activity in your Kubernetes cluster is logged, including user actions, application events and the control plane.

I hope this will be useful as you apply modern security principles to your Kubernetes environment.

 

Gilad David Mayaan

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

Gilad David Mayaan has 5 posts and counting. See all posts by Gilad David Mayaan