Partially Trusting the Service Mesh Control Plane Constantin Adam Abdulhamid Adebayo

2025-05-02 0 0 2.29MB 10 页 10玖币

侵权投诉

Partially Trusting the Service Mesh Control Plane

Constantin Adam

Abdulhamid Adebayo

Hubertus Franke

Edward Snible

Tobin Feldman-Fitzthum

James Cadden

IBM T.J. Watson Research Center

Nerla Jean-Louis

UIUC

Abstract—Zero Trust is a novel cybersecurity model that

focuses on continually evaluating trust to prevent the initiation

and horizontal spreading of attacks. A cloud-native Service Mesh

is an example of Zero Trust Architecture that can ﬁlter out

external threats. However, the Service Mesh does not shield the

Application Owner from internal threats, such as a rogue admin-

istrator of the cluster where their application is deployed. In this

work, we are enhancing the Service Mesh to allow the deﬁnition

and reinforcement of a Veriﬁable Conﬁguration that is deﬁned

and signed off by the Application Owner. Backed by automated

digital signing solutions and conﬁdential computing technologies,

the Veriﬁable Conﬁguration allows changing the trust model

of the Service Mesh, from the data plane fully trusting the

control plane to partially trusting it. This lets the application

beneﬁt from all the functions provided by the Service Mesh

(resource discovery, trafﬁc management, mutual authentication,

access control, observability), while ensuring that the Cluster

Administrator cannot change the state of the application in a

way that was not intended by the Application Owner.

Index Terms—Cloud Security and Privacy, Access Control,

Authorization, Authentication, Trusted Cloud Environments

I. INTRODUCTION

With the widespread adoption of hybrid cloud deployments,

data and application conﬁdentiality remain of paramount

concern, especially in regulated industries, such as ﬁnance,

telecommunications, or healthcare. Zero Trust and Conﬁden-

tial Computing are recent initiatives aiming to address this

problem. Zero Trust is a new cybersecurity model that covers

a collection of concepts and ideas designed to minimize

uncertainty in enforcing accurate, least privilege, per-request

access decisions in information systems and services in the

face of a network viewed as compromised.

Conﬁdential Computing delivers enclaves or trusted ex-

ecution environments (TEE), consisting of either a portion

of an application or an entire virtual machine. Conﬁdential

Computing enables users to compute without exposing their

application or data to the operator of the underlying infrastruc-

ture. They do so by creating an orthogonal privileged domain

separate from the one controlled by the operating system or

hypervisor. This privileged domain is often rooted in hardware

and ﬁrmware; it can be brought up on a system and controlled

and attested independently of the host via trusted hardware

(the Platform Security Processor for AMD, the Management

Engine for Intel, the Ultravisors in IBM Z, and P). In a

cloud environment, the tenant may access and attest the TEE

independently of the state of the host system or other tenants,

thus considerably reducing the trust footprint for running it.

Conﬁdential Computing thus provides an ideal environment

for reducing trust to the levels required by a Zero Trust envi-

ronment by providing at rest, in motion, and use protection for

data inside a security enclave. This ideal security model, which

consists of operation attestation at the beginning and booting

of encrypted images, gives a highly conﬁdential guarantee that

by the time the container is running, the cloud provider has

no access to any data running in that container.

However, deployment in the real world introduces a new

degree of complexity. Most of today’s hybrid cloud-native

applications are distributed and often count on third-party

tools, like sidecars and service meshes, to implement various

security or trafﬁc management functions. For these additional

functions to work, the Conﬁdential Computing security model

of the application has to be relaxed to partially trust the third

party control plane and allow it to interact with the application

containers located inside the security enclave.

The main contribution of this paper is to formally deﬁne

this concept of Partial Trust - how Partial Trust can be

created, established, identiﬁed, and enforced. We describe

the procedure of identifying the line between trusted and

untrusted information using Istio, a popular Service Mesh

implementation, as the motivating example. The concept of

Partial Trust departs from traditional orchestration and Service

Mesh architectures, where the control plane is fully trusted,

and the API between the control and the data plane can be

used to create new containers, conﬁgure the network, or get

logging information.

The rest of the paper is structured as follows. Section II

provides a brief overview of the Service Mesh, focusing

on Istio, and it also deﬁnes the threat model that we are

addressing in this work. Section III discusses in more detail the

supporting technologies for our solution, and reviews related

work. Section IV provides a system overview. We discuss

how this approach can help defending against various attack

techniques in Section V, and conclude in Section VI.

arXiv:2210.12610v1 [cs.CR] 23 Oct 2022

II. PROBLEM

Zero Trust Architecture (ZTA) is an Enterprise CyberSe-

curity Architecture based on Zero Trust principles. Extensive

guidance on transitioning to and implementing ZTA is covered

in [1]. The Istio Service Mesh is a fundamental component in

implementing ZTA for cloud-native applications. The Service

Mesh provides a multitude of functions, such as mutual au-

thentication and encrypted communication between services,

policy propagation and enforcement, certiﬁcate rotation, that

allow to ﬁlter out external attackers and threats.

However, the Service Mesh brings new security risks into

the system, as it does not provide adequate protection for an

Application Owner against the Cloud or Kubernetes admin-

istrators. Running each application pod in a security enclave

shields the pods from attacks originating from the host Oper-

ating System. However, as shown in Figure 1, insiders can use

the interface between the control and data planes of the Service

Mesh to escalate their privileges and abuse them by getting

insights into the current state of the Service Mesh, and then

misconﬁguring it, to change the behavior of the connections,

and of the trafﬁc that is routed along those connections. And

even if the insiders do not act maliciously, many regulations

prohibit the administrators and the operations personnel from

having access to the applications and their data.

In the rest of this section, we highlight the fundamentals of

the Service Mesh architecture with Istio and discuss the threat

model.

A. Service Mesh with Istio

Service Mesh provides a dedicated infrastructure for sup-

porting services in microservices-based applications. Cloud-

based and enterprise applications adopt the microservices

architecture because of its agility, scalability and increasing

availability of automation tools [2]. Service Mesh is designed

to standardize the run-time operations of an application such

as service discovery, load balancing, trafﬁc management [3],

interoperability [4] and dependency control [5]. Istio [6],

started as a collaboration between IBM, Google and Lyft,

Linkerd [7] a 100% Apache-licensed open source product, and

Consul Connect [8], a Service Mesh from Hashicorp, are the

most popular service meshes in the market today.

The increased adoption of the microservices architecture

on a distributed system like Kubernetes results in increased

management complexities. Concepts such as service discovery,

routing, fail-over become prominent as distributed services

communicate with each other. Istio provides an efﬁcient

mechanism to secure and monitor these microservices through

an array of Envoy proxies. Envoy is an OSI L3 and L4

network proxy that uses a chain of network ﬁlters to perform

connection handling. Envoy also supports L7 layer ﬁlters for

HTTP trafﬁc. Many of Istio’s features are enabled by the

underlying built-in attributes of the Envoy proxies.

Istio consists of two components regardless of its deploy-

ment pattern: the data plane and the control plane. The data

plane is the network of microservices whose communication is

routed through Envoy proxies that run alongside the services.

These proxies create the mesh network for the services.

Envoy allows the application of HTTP, gRPC, WebSocket, and

TCP routing rules for ﬁne-grained trafﬁc control. Envoy also

supports security policies and access control for services.

The management of the proxies is done from the control

plane. Istiod dynamically conﬁgures the Envoy sidecar proxies

using a set of discovery APIs, collectively known as the xDS

APIs. The control plane provides conﬁguration, discovery,

and certiﬁcate management for the Envoy proxies at runtime.

Istiod is the component that converts routing rules speciﬁed

in high-level formats such as YAML into Envoy-speciﬁc

conﬁgurations and propagates them to the sidecars. As part

of Istiod,Pilot is responsible for service discovery, Galley

for conﬁguration, and Citadel for certiﬁcate generation. A

fourth component, Mixer, providing extensibility has been

deprecated. The functionality provided by Mixer is now of-

fered through WebAssembly, a sandboxing technology which

can be used to extend the Istio proxy (Envoy). The Proxy-

Wasm sandbox API replaces Mixer as the primary extension

mechanism in Istio.

Istiod provides end-user and service-to-service authenti-

cation with its built-in identity and credential management

component. Istio offers peer authentication and request au-

thentication. For peer authentication, Istio offers mutual TLS

for service-to-service authentication. Istio uses JSON Web

Token (JWT) validation for end-user authentication. Mesh,

namespace, and service-level access control to the Envoy

proxy inbound trafﬁc is enforced using authorization policies.

B. The Threat Model

The adversary in our model is the Cluster Administrator.

Because the adversary has the administrative rights to the

cluster, they can create new objects, and delete or modify the

existing objects in the Kubernetes cluster. We assume that the

workload certiﬁcates are provisioned using a custom certiﬁcate

authority, not the Istio certiﬁcate authority, and the Envoy

proxies are conﬁgured to only accept certiﬁcates issued by the

custom certiﬁcate authority. The adversary cannot, therefore,

tamper with the certiﬁcate management. Also, because the

application pods run in security enclaves controlled by the

Application Owners, the adversary cannot see or modify the

contents of the application pods.

The adversary can interact with the application pods in three

ways. First, they can create, modify, or delete CRDs in the

cluster. The Istio daemon will be notiﬁed of actions and, as

a result, will send the service proxies messages (over their

xDS API interface) that will trigger the reconﬁguration of the

service proxies. Second, the adversary can create new pods

inside the cluster, label them as application components, and

establish communication with the application pods through

these falsely advertised services. Third, the adversary can

poison the Domain Name System (CoreDNS) or the ARP

cache of the cluster.

We cover the ﬁrst scenario described above, when the adver-

sary creates, deletes, or modiﬁes CRDs. For this purpose, we

are using Cosign, a digital signing and verifying technology.

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

PartiallyTrustingtheServiceMeshControlPlaneConstantinAdamAbdulhamidAdebayoHubertusFrankeEdwardSnibleTobinFeldman-FitzthumJamesCaddenIBMT.J.WatsonResearchCenterNerlaJean-LouisUIUCAbstractZeroTrustisanovelcybersecuritymodelthatfocusesoncontinuallyevaluatingtrusttopreventtheinitiationandhorizontalspre...

展开>> 收起<<

Partially Trusting the Service Mesh Control Plane Constantin Adam Abdulhamid Adebayo.pdf

共10页,预览2页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Partially Trusting the Service Mesh Control Plane Constantin Adam Abdulhamid Adebayo

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: