T-Rex’s Zero Trust Reference Architecture: Multi-Cloud

Agencies should closely manage their Zero Trust program when considering a multi-cloud architecture to ensure a secure and zero trust compliant multi-cloud environment. Agencies can maximize these benefits:

• Agency maintains and improves Zero Trust Pillars
• Agency gains security capabilities
• Agency reduces cost

CISA encourages agencies to “use tools that provide a holistic view of their application and infrastructure across all Cloud Service Providers (CSPs) to manage security policy in a centralized way” when operating a multi-cloud environment (Cloud Security Technical Reference Architecture, June 2022, Version 2.0). This article discusses using the Open Policy Agent (OPA) stack for the centralized security policy within a CISA Zero Trust Maturity Model Version 2 while leveraging a NIST Special Publication 800-207: Zero Trust Architecture model within a Kubernetes multi-cloud deployment. This multi-part article series will dive deeper into the implementation of specific policies and Security Information and Event Management (SIEM) integration with common SIEMs. This article is part one of the series.

Why OPA, OPA Gatekeeper, and Kubernetes

Agencies pursue multi-cloud for assorted reasons. The Agency Zero Trust Multi-Cloud table below provides common agency drivers and how OPA and Kubernetes can meet those drivers.

Agency Zero Trust Multi-Cloud Table

Kubernetes core capability is its separation from the hardware infrastructure allowing capabilities to be developed that are not natively supported within CSPs’ infrastructure. This enabler makes Kubernetes an ideal candidate for multi-cloud consideration.

“Our Zero Trust Architecture Accelerator’s generated roadmap ensures agencies can justify and phase in their budgeting and scheduling, optimizing previously generated cybersecurity activities while leveraging inheritance to minimize labor activities,” says T-Rex’s Executive Vice President of Cybersecurity Dr. Allen Harper.

Open Policy Agent (OPA)

Open Policy Agent (OPA), an open-source, general-purpose policy engine, enables unified policy enforcement across the stack. Styra manages OPA, which is available at: Open Policy Agent

OPA provides a declarative policy language for defining policies and a runtime for evaluating those policies against input data. It decouples policy decision-making from the underlying system, allowing the agency to write policies once and apply them consistently across different CSPs, systems, and services.

Specifically, with OPA, you define policies using a high-level declarative language called Rego. Rego allows you to express complex policy logic using a combination of rules, constraints, and data. OPA integrates with various systems, such as API gateways, microservices, IaC tools, and Kubernetes admission controllers. When a system needs to make a policy decision, it sends a request to OPA with the relevant input data. OPA evaluates the request against the defined policies and returns a decision to allow or deny the request.

Gatekeeper, an OPA plugin, and an open-source policy controller for Kubernetes, integrates with OPA to enforce policies on Kubernetes resources. It acts as a Kubernetes admission controller, intercepting brokering requests to the Kubernetes API server and validating or mutating the requested resources based on the defined policies.

Gatekeeper

Gatekeeper uses OPA’s policy language, Rego, to define policies for Kubernetes resources. These policies, known as “constraints,” specify the desired state and requirements for Kubernetes resources, such as pods (the smallest deployable units in Kubernetes), deployments (which manage the lifecycle of pods), services (which provide a stable network endpoint for pods), and more. Gatekeeper translates these constraints into Kubernetes-native resources.

When a request to create, update, or delete a Kubernetes resource comes in, Gatekeeper intercepts the request before the Kubernetes API server generates a response. It then evaluates the request against the defined constraints using OPA’s policy evaluation engine. If the request violates any of the policy’s constraints, Gatekeeper can either deny the request entirely or mutate the resource to bring it into compliance with the policies.

Gatekeeper provides a declarative and centralized way to enforce policies across a Kubernetes cluster. It enables administrators to define and manage policies as code, ensuring consistent policy enforcement and reducing the risk of misconfigurations (incorrect or suboptimal settings). Gatekeeper supports a wide range of policy scenarios, such as enforcing naming conventions, resource quotas (limits on the number of resources used), pod security policies (which control the security-related aspects of pods), and more.

Gatekeeper Features

The table Sampling of Gatekeeper Features shows a sampling of Gatekeeper’s key features and alignment with CISA’s ZT Maturity Model.

Sampling of Gatekeeper Features

These features will enable us to apply key capabilities with specific results.  The following features provides insight  into translating the Kubernetes features to specific results.

Example Kubernetes Features

A closer look at the NIST Zero Trust Architecture will show the roles played by OPA, OPA Gatekeeper, and Kubernetes functions in ensuring a Zero Trust Architecture (ZTA).

Zero Trust Architecture in Action with OPA and OPA Gatekeeper

A NIST Zero Trust Architecture (NIST SP 800-207 Zero Trust Architecture:  Zero Trust Architecture (nist.gov)) defines policy and policy enforcement through an architecture with two discrete functions: Policy Decision Point (PDP) and Policy Enforcement Point (PEP). The PDP determines if a session should move from an untrusted to trusted state, and the PEP carries out the policy decision point’s decision: either allowing access to the resource or blocking the access.

The PDP contains two logical components: the Policy Engine and the Policy Administrator.

• Policy Engine (PE): The PE makes the decision to grant access to a resource or not.  The PE simplifies Zero Trust implementation as it conducts querying external resources that influence the decisions such as threat intelligence, network access rules (vertical, lateral rules), etc., to determine to allow or deny a session to the specific service requested.
• Policy Administrator (PA): Once the PE determines to allow or deny the specific session, the PA manages the communication point between the requester and resource destination by communicating to the PEP.

Marrying OPA, OPA Gatekeeper and the NIST Zero Trust Architecture

In the context of the ZTA described in NIST Special Publication 800-207, Open Policy Agent (OPA) and OPA Gatekeeper would play the role of PDP and PEP components, respectively.

OPA as a PDP

OPA is an open-source, general-purpose policy engine that enables unified policy enforcement across the stack. As a PDP, OPA evaluates access requests against defined policies to determine whether access should be granted.

In the ZTA, OPA would receive access requests from PEPs and make authorization decisions based on the configured policies.

OPA Gatekeeper as a PEP

OPA Gatekeeper integrates with the Kubernetes admission controller that integrates with OPA to enforce policies on Kubernetes resources.

As a PEP, OPA Gatekeeper would intercept requests to the Kubernetes API server and enforce the policies defined in OPA.

Gatekeeper acts as a “gatekeeper” for Kubernetes, validating and mutating resources based on the policies before you create, update, or delete resources.

In the ZTA context, OPA Gatekeeper would enforce the access policies determined by OPA (PDP) on Kubernetes resources, ensuring that engineers can only carry out authorized actions.

The following diagram shows the logical policy flow within the multi-cloud

Zero Trust Reference Architecture: Multi-Cloud

Gatekeeper Example

Gatekeeper comes with a number of polices that support pod and container level security. One of these standard libraries is the support of immutable root file systems which blocks write access to the underlying file system. This immutable support is often desirable for web facing applications and some security applications such as honeypots.

To use the Gatekeeper library read-only-root we must ingest it into our cluster:

root@k8s-controller:/# kubectl apply -f /root/gatekeeper-library/library/pod-security-policy/read-only-root-filesystem/template.yaml

The cluster will then report the gatekeeper constraint was created:

constrainttemplate.templates.gatekeeper.sh/k8spspreadonlyrootfilesystem created

We can then create a policy. This is the policy:

root@k8s-controller:# cat K8sPSPReadOnlyRootFilesystem.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1

kind: K8sPSPReadOnlyRootFilesystem

metadata:

name: psp-readonlyrootfilesystem

spec:

match:

kinds:

- apiGroups: [""]

kinds: ["Pod”]

The policy statement kinds, applies it to pods. Let’s apply it to our cluster:

Kubectl apply -f cat K8sPSPReadOnlyRootFilesystem.yaml

Now consider the test.yaml file to create a container that tries to create a writeable root file system (readOnlyRootFilesystem: false):

apiVersion: v1

kind: Pod

metadata:

name: testpod

labels:

app: nginx-readonlyrootfilesystem

spec:

containers:

- name: nginx

image: nginx

securityContext:

readOnlyRootFilesystem: false

When creating the container that has a writeable root file system, Gatekeeper intercepted and blocked the request.

root@k8s-controller:~/pods# k apply -f test.yaml

Error from server (Forbidden): error when creating "test.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [psp-readonlyrootfilesystem] only read-only root filesystem container is allowed: nginx

Conclusion

This combination of OPA and OPA Gatekeeper aligns with the ZTA principles of least privilege access, continuous monitoring and authorization, and dynamic policy enforcement. OPA acts as the central policy decision point, evaluating access requests against defined policies, while OPA Gatekeeper enforces those decisions on Kubernetes resources, ensuring staff maintain the desired security posture throughout the system while reducing costs through the efficiencies brought with policy as code.

In seeking innovative ways to mature the agency Zero Trust posture, T-Rex cyber engineers take a complete cyber approach, applying Zero Trust principals. This article has focused on improving your agency’s multi-cloud Zero Trust posture.

T-Rex’s cybersecurity engineers and architects work with Federal agencies to speed their Zero Trust endeavors through T-Rex’s Zero Trust Architecture Accelerator 2.0 and innovative approaches as shown here. Contact us at cybersecurity@trexsolutionsllc.com to discuss how we can assist in your Zero Trust program.