nist -云原生應用的服務網格代理模型 RService Mesh Proxy Models for Cloud-Native Applications

NISTSpecialPublication800NISTSP800-233

ServiceMeshProxyModelsforCloud-NativeApplications

RamaswamyChandramouliZackButcher

JamesCallaghan

Thispublicationisavailablefreeofchargefrom:

/10.6028/NIST.SP.800-233

NISTSpecialPublication800NISTSP800-233

ServiceMeshProxyModelsforCloud-NativeApplications

RamaswamyChandramouli

ComputerSecurityDivisionInformationTechnologyLaboratory

ZackButcher

Tetrate,Inc.

JamesCallaghan

control-plane.io,

Inc.

Thispublicationisavailablefreeofchargefrom:

/10.6028/NIST.SP.800-233

October2024

U.S.DepartmentofCommerce

GinaM.Raimondo,Secretary

NationalInstituteofStandardsandTechnology

LaurieE.Locascio,NISTDirectorandUnderSecretaryofCommerceforStandardsandTechnology

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

Certaincommercialequipment,instruments,software,ormaterials,commercialornon-commercial,areidentified

inthispaperinordertospecifytheexperimentalprocedureadequately.SuchidentificationdoesnotimplyrecommendationorendorsementofanyproductorservicebyNIST,nordoesitimplythatthematerialsorequipmentidentifiedarenecessarilythebestavailableforthepurpose.

TheremaybereferencesinthispublicationtootherpublicationscurrentlyunderdevelopmentbyNISTin

accordancewithitsassignedstatutoryresponsibilities.Theinformationinthispublication,includingconceptsandmethodologies,maybeusedbyfederalagenciesevenbeforethecompletionofsuchcompanionpublications.

Thus,untileachpublicationiscompleted,currentrequirements,guidelines,andprocedures,wheretheyexist,

remainoperative.Forplanningandtransitionpurposes,federalagenciesmaywishtocloselyfollowthedevelopmentofthesenewpublicationsbyNIST.

OrganizationsareencouragedtoreviewalldraftpublicationsduringpubliccommentperiodsandprovidefeedbacktoNIST.ManyNISTcybersecuritypublications,otherthantheonesnotedabove,areavailableat

/publications.

Authority

ThispublicationhasbeendevelopedbyNISTinaccordancewithitsstatutoryresponsibilitiesundertheFederal

InformationSecurityModernizationAct(FISMA)of2014,44U.S.C.§3551etseq.,PublicLaw(P.L.)113-283.NISTisresponsiblefordevelopinginformationsecuritystandardsandguidelines,includingminimumrequirementsfor

federalinformationsystems,butsuchstandardsandguidelinesshallnotapplytonationalsecuritysystems

withouttheexpressapprovalofappropriatefederalofficialsexercisingpolicyauthorityoversuchsystems.ThisguidelineisconsistentwiththerequirementsoftheOfficeofManagementandBudget(OMB)CircularA-130.

Nothinginthispublicationshouldbetakentocontradictthestandardsandguidelinesmademandatoryand

bindingonfederalagenciesbytheSecretaryofCommerceunderstatutoryauthority.NorshouldtheseguidelinesbeinterpretedasalteringorsupersedingtheexistingauthoritiesoftheSecretaryofCommerce,Directorofthe

OMB,oranyotherfederalofficial.ThispublicationmaybeusedbynongovernmentalorganizationsonavoluntarybasisandisnotsubjecttocopyrightintheUnitedStates.Attributionwould,however,beappreciatedbyNIST.

NISTTechnicalSeriesPolicies

Copyright,Use,andLicensingStatements

NISTTechnicalSeriesPublicationIdentifierSyntax

PublicationHistory

ApprovedbytheNISTEditorialReviewBoardon2024-10-11

HowtoCitethisNISTTechnicalSeriesPublication:

ChandramouliR,ButcherZ,CallaghanJ(2024)ServiceMeshProxyModelsforCloud-NativeApplications.(NationalInstituteofStandardsandTechnology,Gaithersburg,MD),NISTSpecialPublication(SP)NISTSP800-233.

/10.6028/NIST.SP.800-233

AuthorORCIDiDs

RamaswamyChandramouli:0000-0002-7387-5858

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

ContactInformation

sp800-233-comments@

NationalInstituteofStandardsandTechnology

Attn:ComputerSecurityDivision,InformationTechnologyLaboratory

100BureauDrive(MailStop8930)Gaithersburg,MD20899-8930

AdditionalInformation

Additionalinformationaboutthispublicationisavailableat

/pubs/sp/800/233/final,

includingrelatedcontent,potentialupdates,anddocumenthistory.

AllcommentsaresubjecttoreleaseundertheFreedomofInformationAct(FOIA).

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

i

Abstract

Theservicemeshhasbecomethedefactoapplicationservicesinfrastructureforcloud-nativeapplications.Itenablesthevariousruntimefunctionsofanapplicationthroughproxiesthat

formthedataplaneoftheservicemesh.Dependingonthedistributionofthenetworklayer

functionsandthegranularityofassociationoftheproxiestoindividualservicesandcomputingnodes,differentproxymodelsordataplanearchitectureshaveemerged.Thisdocument

describesathreatprofileforeachofthedataplanearchitectureswithadetailedthreatanalysistomakerecommendationsontheirapplicabilityforcloud-nativeapplicationswithdifferent

securityriskprofiles.

Keywords

cloud-nativeapplication;dataplanearchitecture;proxymodel;servicemesh;threatprofile.

ReportsonComputerSystemsTechnology

TheInformationTechnologyLaboratory(ITL)attheNationalInstituteofStandardsandTechnology(NIST)promotestheU.S.economyandpublicwelfarebyprovidingtechnical

leadershipfortheNation’smeasurementandstandardsinfrastructure.ITLdevelopstests,testmethods,referencedata,proofofconceptimplementations,andtechnicalanalysestoadvance

thedevelopmentandproductiveuseofinformationtechnology.ITL’sresponsibilitiesincludethedevelopmentofmanagement,administrative,technical,andphysicalstandardsand

guidelinesforthecost-effectivesecurityandprivacyofotherthannationalsecurity-related

informationinfederalinformationsystems.TheSpecialPublication800-seriesreportsonITL’sresearch,guidelines,andoutreacheffortsininformationsystemsecurity,anditscollaborativeactivitieswithindustry,government,andacademicorganizations.

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

ii

PatentDisclosureNotice

NOTICE:ITLhasrequestedthatholdersofpatentclaimswhoseusemayberequiredfor

compliancewiththeguidanceorrequirementsofthispublicationdisclosesuchpatentclaimstoITL.However,holdersofpatentsarenotobligatedtorespondtoITLcallsforpatentsandITLhasnotundertakenapatentsearchinordertoidentifywhich,ifany,patentsmayapplytothis

publication.

Asofthedateofpublicationandfollowingcall(s)fortheidentificationofpatentclaimswhoseusemayberequiredforcompliancewiththeguidanceorrequirementsofthispublication,nosuchpatentclaimshavebeenidentifiedtoITL.

NorepresentationismadeorimpliedbyITLthatlicensesarenotrequiredtoavoidpatentinfringementintheuseofthispublication.

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

iii

TableofContents

ExecutiveSummary 1

1.Introduction 2

1.1.L4andI7Functionsofproies…3

12.0bectieandTargetAudience.…………3

13.elationshiptootherNISTDocuments………………4

1.4.Documentstucture…4

2.TypicalServiceMeshDataPlaneCapabilitiesandAssociatedProxyFunctions 5

3.ProxyModels(DataPlaneArchitectures)inServiceMeshImplementations 7

31.L4and17proxypersericelnstance(OPA-)-sidecarModel…7

32.sharedL4-L7perseniceModel(OPA.2h……….8

3.3.sharedL4andL7Model(DPA-3).........9

3.A,L4andL7aspartoftheApplicationModel(OPA-4)l………10

4.DataPlaneArchitectureThreatScenariosandAnalysisMethodology 12

4.1.ThreatAnalsiMethodology….13

5.DetailedThreatAnalysisforDataPlaneArchitectures 14

5.1.ThreatAnalysisforL4andL7proxyperserviceInstance(DPA-1)—sidecarModel...........14

5.1.1.CompromisedL4Proxy(TR-1) 14

5.1.2.CompromisedApplicationContainer(TR-2) 14

5.1.3.CompromiseofBusinessData(TR-3) 15

5.1.4.CompromisedL7Proxy(TR-4) 15

5.1.5.CompromiseofSharedL7Proxy(TR-5) 15

5.1.6.OutdatedClientLibrariesinApplications(TR-6) 16

5.1.7.DenialofService(TR-7) 16

5.1.8.ResourceConsumption(TR-8) 17

5.1.9.PrivilegedL4Proxy(TR-9) 17

5.1.10.DataPlane(ServiceMesh)Bypassed(TR-10) 17

5.1.11OverallThreatScore 18

52.ThreatAnalysisforsharedL4-L7perseniceModel(OPA-2)……18

5.2.1.CompromisedL4Proxy(TR-1) 18

5.2.2.CompromisedApplicationContainer(TR-2) 18

5.2.3.CompromiseofBusinessData(TR-3) 18

5.2.4.CompromisedL7Proxy(TR-4) 19

5.2.5.CompromiseofSharedL7Proxy(TR-5) 19

5.2.6.OutdatedClientLibrariesinApplications(TR-6) 19

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

iv

5.2.7.DenialofService(TR-7) 19

5.2.8.ResourceConsumption(TR-8) 20

5.2.9PrivilegedL4Proxy(TR-9) 20

5.2.10DataPlane(ServiceMesh)Bypassed(TR-10) 21

5.2.11OverallThreatScore 21

5.3.1.CompromisedL4Proxy(TR-1) 21

5.3.2.CompromisedApplicationContainer(TR-2) 22

5.3.3.CompromiseofBusinessData(TR-3) 22

5.3.4.CompromisedL7Proxy(TR-4) 22

5.3.5.CompromiseofSharedL7Proxy(TR-5) 23

5.3.6.OutdatedClientLibrariesinApplications(TR-6) 23

5.3.7.DenialofService(TR-7) 23

5.3.8.ResourceConsumption(TR-8) 23

5.3.9.PrivilegedL4Proxy(TR-9) 24

5.3.10.DataPlane(ServiceMesh)Bypassed(TR-10) 24

5.3.11OverallThreatScore 24

5.4.ThreatAnalysisforL4andL7aspartoftheApplicationModel(gRpcproxylessModel(DPA-4))

25

5.4.1.CompromisedL4Proxy(TR-1) 25

5.4.2.CompromisedApplicationContainer(TR-2) 25

5.4.3.CompromiseofBusinessData(TR-3) 25

5.4.4.CompromisedL7Proxy(TR-4) 25

5.4.5.CompromiseofSharedL7Proxy(TR-5) 26

5.4.6.OutdatedClientLibrariesinApplications(TR-6) 26

5.4.7.DenialofService(TR-7) 26

5.4.8.ResourceConsumption(TR-8) 27

5.4.9PrivilegedL4Proxy(TR-9) 27

5.4.10DataPlane(ServiceMesh)Bypassed(TR-10) 27

5.4.11OverallThreatScore 28

6.RecommendationsBasedontheApplicationSecurityRiskProfile 29

7.SummaryandConclusions............................................................................................................32

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

v

References.......................................................................................................................................33

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

vi

Acknowledgments

TheauthorswouldliketoexpresstheirthankstoFrancescoBeltraminiofcontrol-plane.ioforparticipatingindiscussionsandprovidinghisvaluableperspective.TheauthorswouldalsoliketoexpresstheirthankstoIsabelVanWykofNISTforherdetailededitorialreview,bothforthepubliccommentversionaswellasforthefinalpublication

1

ExecutiveSummary

Acentralizedinfrastructurecalledaservicemeshcanproviderun-timeservicesforcloud-nativeapplicationsthatconsistofmultiplelooselycoupledcomponentscalledmicroservices.These

servicesincludesecurecommunication,servicediscovery,resiliency,andauthorizationof

applicationcommunication.Theseservicesaremainlyprovidedthroughproxiesthatformthedataplaneoftheservicemesh,whichisthelayerthathandlesapplicationtrafficatruntime

andenforcespolicy.

ThefunctionsthattheproxiesprovidecanbebroadlycategorizedintotwogroupsbasedontheOpenSystemsInterconnection(OSI)model’snetworklayertowhichthosefunctionspertain:

Layer4(“L4”)andLayer7(“L7”).Inmostservicemeshdeploymentsinproduction

environmentstoday,allproxyfunctionsthatprovideservicesinbothL4andL7layersare

packedintoasingleproxythatisassignedtoasinglemicroservice.Thisservicemeshproxy

modeliscalledasidecarproxymodelsincetheproxyisnotonlyassociatedwithasingleservicebutisimplementedtoexecuteinthesamenetworkspaceastheservice.

However,performanceandresourceconsiderationshaveledtotheexplorationofalternate

proxymodelsthatinvolvesplittingL4andL7functionsintodifferentproxiesandthe

associationorassignmentsoftheseproxiestoeitherasingleserviceoragroupofservices.Thisenablestheproxiestobeimplementedatdifferentlocationsatthegranularityofanoderatherthanatthelevelofservices.Thoughdifferentmodelsaretheoreticallypossible,thisdocumentonlyconsidersservicemeshproxymodelsinthedataplaneimplementationofcommonlyusedservicemeshofferingsatdifferentstages.

Variouspotentialorlikelythreatstoproxyfunctionsmayresultindifferenttypesofexploitsindifferentproxymodels.Thisvariationisduetoseveralfactors,suchastheattacksurface(i.e.,

communicationpatternstowhichaparticularproxyisexposed),thenumberofclients

(services)served,andtheOSIlayerfunctionsthattheyprovide(e.g.,L7functionsaremorecomplicatedandlikelytohavemorevulnerabilitiesthanL4functions).Thetwomain

contributionsofthisdocumentarethefollowing:

1.Thenatureoftheexploitsthatarepossibleforeachthreatineachoftheproxymodelsischaracterizedbyassigningscorestotheimpactandlikelihoodofeachofthethreatsineachoftheproxymodelsorarchitecturalpatterns,resultinginathreatprofilethatis

associatedwitheacharchitecturalpatternorproxymodelofservicemesh.

2.Eachthreatprofilehasaninherentsetofsecuritytrade-offsatanarchitecturallevel.

Theimplicationsofthesetrade-offsinmeetingtherequirementsassociatedwiththe

securityriskprofilesofdifferentcloud-nativeapplicationsareanalyzedtomakeabroadsetofrecommendationstowardspecificarchitecturalpatternsthatareappropriateforapplicationswithdifferentsecurityriskprofiles.

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

2

1.Introduction

“Cloud-native”referstoanarchitecturalphilosophyforbuildingscalable,resilientsystemsthat

aredesignedtoleveragetheadvantagesofcloudcomputingenvironments.Cloud-native

applicationscanrunbothon-premisesandinpubliccloudplatformsandarenormallybuilt

usingagiledevelopmentmethodologies,suchascontinuousintegration/continuousdelivery(CI/CD).Typically,technologiessuchascontainerizationandvirtualmachines(VMs)areused,andresilienceandfail-safefeatureswillbebuiltin.

Microservices-basedapplicationsuseanarchitecturalapproachinwhichtheentireapplicationisbrokenintolooselycoupledcomponentsthatcanbeindependentlyupdatedandscaled.Theimplementationofmicroservicesisenabledusingcontainersthatinturnrequireorchestrationtoolsandoftenemployacentralizedservicesinfrastructure(e.g.,servicemesh)toprovideallruntimeapplicationservices,includingnetworkconnectivity,security,resiliency,and

monitoringcapabilities.Microservices-basedapplicationscanbeimplementedanddeployedascloud-native,thoughtheyrepresentanindependentarchitecturalapproach.

Theinfrastructureservicesorfunctionsprovidedbyaservicemeshduringapplicationruntimeareprovidedbyentitiescalledproxies,whichconstitutethedataplaneoftheservicemesh.Inaddition,theservicemeshconsistsofanotherarchitecturalcomponentcalledthecontrol

plane,whichsupportsthefunctionsofthedataplanethroughinterfacestodefine

configurations,injectsoftwareprograms,andprovidesecurityartifacts(e.g.,certificates).

Variousconfigurationsforproxiesarebeingdevelopedandtestedbasedontheperformanceandsecurityassurancedataobtainedduringthedeploymentofservicemeshoverthelast

severalyears.Theseconfigurationsareproxy(implementation)modelsthatarebasedontheOSIlayerfunctionsthattheyprovide(describedinthefollowingparagraphs)andthe

granularityofassociationbetweenaproxyandservices.Sinceproxiesarethepredominantentitiesofthedataplaneofaservicemesh,thesevariousproxymodelsarealsocalleddataplanearchitectures.

TheOSImodel

[1]

isausefulabstractionforthinkingaboutthefunctionsrequiredtoserveanapplicationoverthenetwork.Itdescribesseven“l(fā)ayers,”fromthephysicalwiresthatconnecttwomachines(i.e.,Layer1–L1,thephysicallayer)totheapplicationitself(i.e.,Layer7–L7,theapplicationlayer).

Layers3,4,and7arekeytofacilitatingcommunicationbetweencloud-nativeapplications(e.g.,twomicroservicesmakingHypertextTransferProtocol(HTTP)/RESTcallstoeachother):

?Layer3(“L3”),thenetworklayer,facilitatesbaselineconnectivitybetweentwo

workloadsorserviceinstances.Innearlyallcases,theInternetProtocol(IP)isusedastheL3implementation.

?Layer4(“L4”),thetransportlayer,facilitatesthereliabletransmissionofdatabetweenworkloadsonthenetwork.Italsoincludescapabilitieslikeencryption.TransportControlProtocol(TCP)andUserDatagramProtocol(UDP)arecommonlyusedL4

implementations,wheretransportlayersecurity(TLS)providesencryption.

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

3

?Layer7(“L7”),theapplicationlayer,iswhereprotocolslikeHTTPoperate—inuserapplicationsthemselves(e.g.,HTTPwebservers,SecureShell(SSH)servers).

Withrespecttothelayersabove,aservicemesh’sproxiesincloud-nativeenvironmentsare:

?AgnostictoL3ifthemicroserviceinstancescancommunicateatL3andtheproxycancommunicatewiththemesh’scontrolplane.

?AtLayer4(L4):Connectionestablishment,management,andresiliency(e.g.,

connection-levelretries);TLS(encryptionintransit);applicationidentity,authentication,andauthorization;accesspolicybasedonnetwork5-tuple(e.g.,sourceIPaddressand

port,destinationIPaddressandport,andtransportprotocol).

?AtLayer7(L7):Servicediscovery,request-levelresiliency(e.g.,retries,circuitbreakers,

outlierdetection);andapplicationobservability.

1.1.L4andL7FunctionsofProxies

Therearetwokeyaspectsofproxymodels:

1.Proxyfunctions:Thefunctionsthataservicemesh’sproxiesprovidecanbebroadly

categorizedintotwogroupsbasedontheOSImodel’slayer

[1]

towhichthosefunctionspertain:Layer4(“L4”)andLayer7(“L7”).TheassociatedproxiesarecalledL4proxies

andL7proxies,respectively.ThestudyofproxyfunctionsrequiresanunderstandingoftheOSI’sL4andL7layersfromthenetworkstackpointofviewandthespecificnetworkservicesprovidedbythoselayers.

2.Granularityofassociation:Aproxycanbeassociatedwithasinglemicroserviceinstance,anentireservice,ordeployedtoprovidefunctionsforagroupofservices.Dependingonthenatureofthisassociation,aproxymayexecutewithinthesamenetworkspaceas

theservice,atthesamenodewherethegroupofservicestowhichitcatersrun,orinanindependentnodededicatedtoproxieswherenoapplicationservicesrun.

1.2.ObjectiveandTargetAudience

Thisdocumentwillgiveabriefoverviewofthefourdataplanearchitectures(proxymodels)beingpursuedbyarangeofservicemeshimplementationstoday.Itwillalsoprovidethreatprofilesfordifferentproxymodelswithadetailedthreatanalysisthatinvolves10typesofcommonthreats.Thesethreatprofileswillinformrecommendationsregardingtheir

applicability(usage)forcloud-nativeapplicationswithdifferentsecurityriskprofiles.Thetargetaudiencefortheserecommendationsincludes:

?Infrastructureowners,platform/infrastructureengineers,andtheirteamleaderswhobuildanddeploysecureruntimeenvironmentsforapplicationsbychoosingtherightarchitecturefortheirenvironmentgiventheriskfactorsoftheapplicationsthattheywillberunningandtheresultingsecurityriskprofile.

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

4

?Personnelinchargeofinfrastructureoperationswhoneedtobefamiliarwiththe

variousbuildingblocksoftheproxymodelsordataplanearchitectures(andtheir

associatedfunctionsandinteractions)totroubleshootintheeventofperformance(i.e.,availability)andsecurityissues

1.3.RelationshiptoOtherNISTDocuments

ThisdocumentcanbeusedasanadjuncttotheNISTSpecialPublication(SP)800-204seriesofpublications

[2][3][4][5],

whichofferguidanceonprovidingsecurityassuranceforcloud-native

applicationsintegratedwithaservicemeshfromthefollowingperspectives:strategy,

configuration,anddevelopment/deploymentparadigm.However,thisdocumentfocuseson

thevariousconfigurationsoftheapplicationserviceinfrastructureelements(i.e.,proxies)andtheresultingarchitectures(i.e.,dataplanearchitectureoftheservicemesh)thathavedifferent

securityimplicationsfortheapplicationthatishostedundereachoftheseconfigurations.

1.4.DocumentStructure

Thisdocumentisorganizedasfollows:

?

?

?

?

?

?

Section

2

liststhetypicalcapabilitiesofthedataplaneoftheservicemeshunderthreeheadings(i.e.,security,observability,andtrafficmanagement)andthecorrespondingL4andL7proxyfunctionsimplementedunderthosecapabilities.

Section

3

providesabriefoverviewofthefourproxymodelsordataplanearchitectures.Section

4

discussesproxymodelthreatscenariosandthethreatanalysismethodologyadoptedinthisdocumentforevaluatingthethreatprofilescoreforthefourdataplanearchitectures.

Section

5

providesadetailedthreatanalysisforthefourdataplanearchitecturesbyassigningscorestotheimpactandlikelihoodfactorsassociatedwitheachthreatandusingthemtoarriveatanoverallthreatscore.

Section

0

providesrecommendationsontheapplicability(usage)ofeachofthefourdataplanearchitecturesforcloud-nativeapplicationsofdifferentsecurityriskprofilesbasedontheirsecurityrequirements.

Section

0

providesthesummaryandconclusions.

NISTSP800-233ServiceMeshProxyModelsfor

October2024Cloud-NativeApplications

5

2.TypicalServiceMeshDataPlaneCapabilitiesandAssociatedProxyFunctions

Thisdocument’smethodologyexaminesthesecuritytrade-offsoftheproxymodels(i.e.,data

planearchitectures)andtheimplementationsofthevariouscapabilitiesthatresultasL4andL7functionsinproxies.Determiningthetotalityofproxyfunctionsrequiresananalysisofeach

capability,thecategoryitfallsunder,andthegranularityofthefunctionthatitprovidesatL4andL7levels.

Table1-SecurityCapabilities[15]

Capability

L4Function(s)

L7Function(s)

Service-to-serviceauthentication

SPIFFE,

viamTLScerts.Control

planeissuesashort-livedX.509

encodingt