Dela via

X.509-certifikatbaserad autentisering i Service Fabric-kluster

  • Artikel

Den här artikeln kompletterar introduktionen till Service Fabric-klustersäkerhet och går in på information om certifikatbaserad autentisering i Service Fabric-kluster. Vi antar att läsaren är bekant med grundläggande säkerhetsbegrepp och även med de kontroller som Service Fabric exponerar för att kontrollera säkerheten för ett kluster.

Ämnen som beskrivs i den här rubriken:

  • Grundläggande certifikatbaserad autentisering
  • Identiteter och deras respektive roller
  • Konfigurationsregler för certifikat
  • Felsökning och vanliga frågor och svar

Grundläggande certifikatbaserad autentisering

Som en kort uppdatering är ett certifikat i säkerhet ett instrument som är avsett att binda information om en entitet (ämnet) till deras innehav av ett par asymmetriska kryptografiska nycklar, och utgör därför en kärnkonstruktion av kryptering av offentliga nycklar. Nycklarna som representeras av ett certifikat kan användas för att skydda data eller för att bevisa nyckelinnehavarnas identitet. När det används tillsammans med ett PKI-system (Public Key Infrastructure) kan ett certifikat representera ytterligare egenskaper i ämnet, till exempel ägarskapet för en Internetdomän eller vissa privilegier som certifikatutfärdaren har beviljat det (kallas certifikatutfärdare eller CERTIFIKATUTFÄRDARE). En vanlig tillämpning av certifikat stöder krypteringsprotokollet Transport Layer Security (TLS), vilket möjliggör säker kommunikation via ett datornätverk. Mer specifikt använder klienten och servern certifikat för att säkerställa sekretessen och integriteten i kommunikationen, och även för att utföra ömsesidig autentisering.

I Service Fabric bygger det grundläggande lagret i ett kluster (Federation) också på TLS (bland andra protokoll) för att uppnå ett tillförlitligt och säkert nätverk av deltagande noder. Anslutningar till klustret via Service Fabric-klient-API:er använder även TLS för att skydda trafiken och även för att fastställa parternas identiteter. När det används för autentisering i Service Fabric kan ett certifikat användas för att bevisa följande anspråk: a) presentatören av certifikatautentiseringsuppgifterna har tillgång till certifikatets privata nyckel b) certifikatets SHA-1-hash (tumavtryck) matchar en deklaration som ingår i klusterdefinitionen, eller c) certifikatets unika gemensamma ämnesnamn matchar en deklaration som ingår i klusterdefinitionen, certifikatutfärdaren är känd eller betrodd.

I listan ovan kallas "b" vardagligt för "tumavtrycksstiftning"; I det här fallet hänvisar deklarationen till ett specifikt certifikat och styrkan i autentiseringsschemat vilar på antagandet att det är beräkningsmässigt omöjligt att förfalska ett certifikat som genererar samma hashvärde som ett annat, samtidigt som det fortfarande är ett giltigt, välformat objekt i alla andra avseenden. Punkt c representerar en alternativ form av att deklarera ett certifikat, där systemets styrka vilar på kombinationen av certifikatets ämne och den utfärdande myndigheten. I det här fallet refererar deklarationen till en klass med certifikat – två certifikat med samma egenskaper anses vara helt likvärdiga.

I följande avsnitt beskrivs ingående hur Service Fabric-körningen använder och validerar certifikat för att säkerställa klustersäkerhet.

Identiteter och deras respektive roller

Innan du går in på information om autentisering eller säkrar kommunikationskanaler är det viktigt att lista de deltagande aktörerna och motsvarande roller som de spelar i ett kluster:

  • Service Fabric-körningen, som kallas "system": den uppsättning tjänster som tillhandahåller abstraktioner och funktioner som representerar klustret. När vi refererar till kommunikation i klustret mellan systeminstanser använder vi termen "klusteridentitet". När vi refererar till klustret som mottagare/mål för trafik utanför klustret använder vi termen "serveridentitet".
  • värdbaserade program, som kallas "program": kod som tillhandahålls av klustrets ägare, som dirigeras och körs i klustret
  • klienter: entiteter som tillåts ansluta till och köra funktioner i ett kluster enligt klusterkonfigurationen. Vi skiljer mellan två behörighetsnivåer – "användare" respektive "administratör". En "användarklient" begränsas främst till skrivskyddade åtgärder (men inte alla skrivskyddade funktioner), medan en administratörsklient har obegränsad åtkomst till klustrets funktioner. (Mer information finns i Säkerhetsroller i ett Service Fabric-kluster.)
  • (Endast Azure) De Service Fabric-tjänster som samordnar och exponerar kontroller för drift och hantering av Service Fabric-kluster, som bara kallas "tjänst". Beroende på miljön kan "tjänsten" referera till Azure Service Fabric-resursprovidern eller andra resursproviders som ägs och drivs av Service Fabric-teamet.

I ett säkert kluster kan var och en av dessa roller konfigureras med sin egen, distinkta identitet, som deklareras som parkoppling av ett fördefinierat rollnamn och motsvarande autentiseringsuppgifter. Service Fabric har stöd för att deklarera autentiseringsuppgifter som certifikat eller domänbaserat huvudnamn för tjänsten. (Windows-/Kerberos-baserade identiteter stöds också, men ligger utanför den här artikelns omfång. Mer information finns iWindows-baserad säkerhet i Service Fabric-kluster.) I Azure-kluster kan klientroller också deklareras som Microsoft Entra-ID-baserade identiteter.

Som nämnts ovan definierar Service Fabric-körningen två behörighetsnivåer i ett kluster: "admin" och "användare". En administratörsklient och en systemkomponent skulle båda fungera med administratörsbehörigheter och kan därför inte skiljas från varandra. När du upprättar en anslutning i/till klustret beviljas en autentiserad anropare av Service Fabric-körningen en av de två rollerna som bas för den efterföljande auktoriseringen. Vi undersöker autentiseringen på djupet i följande avsnitt.

Konfigurationsregler för certifikat

Valideringsregler

Säkerhetsinställningarna för ett Service Fabric-kluster beskriver i princip följande aspekter:

  • autentiseringstypen. Det här är en oföränderlig egenskap för klustret. Exempel på sådana inställningar är "ClusterCredentialType", "ServerCredentialType" och tillåtna värden är "none", "x509" eller "windows". Den här artikeln fokuserar på x509-typautentisering.
  • Valideringsreglerna för (autentisering). dessa inställningar anges av klusterägaren och beskriver vilka autentiseringsuppgifter som ska godkännas för en viss roll. Exempel kommer att undersökas på djupet direkt nedan.
  • inställningar som används för att justera eller subtilt ändra resultatet av autentiseringen. Exempel här är flaggor som begränsar eller obegränsade tillämpning av listor över återkallade certifikat osv.

Kommentar

Exempel på klusterkonfiguration som anges nedan är utdrag från klustermanifestet i XML-format, som det mest sammanfattade formatet som stöder direkt service fabric-funktionerna som beskrivs i den här artikeln. Samma inställningar kan uttryckas direkt i JSON-representationerna av en klusterdefinition, oavsett om det är ett fristående json-klustermanifest eller en Azure Resource Mangement-mall.

En verifieringsregel för certifikat består av följande element:

  • motsvarande roll: klient, administratörsklient (privilegierad roll)
  • de autentiseringsuppgifter som godkänts för rollen, deklarerade antingen med tumavtryck eller ämnesnamn

Valideringsdeklarationer för tumavtrycksbaserade certifikat

När det gäller tumavtrycksbaserade valideringsregler verifieras de autentiseringsuppgifter som visas av en anropare som begär en anslutning i/till klustret på följande sätt:

  • Autentiseringsuppgiften är ett giltigt, välformat certifikat: dess kedja kan skapas, signaturer matchar
  • certifikatet är tidsgiltigt (NotBefore <= nu < NotAfter)
  • certifikatets SHA-1-hash matchar deklarationen, som en skiftlägeskänslig strängjämförelse exklusive alla blanksteg

Eventuella förtroendefel som påträffas under kedjeskapande eller validering kommer att ignoreras för tumavtrycksbaserade deklarationer, förutom för utgångna certifikat , även om det finns bestämmelser även för det fallet. Mer specifikt betraktas fel som rör: återkallandestatusen är okänd eller offline, ej betrodd rot, ogiltig nyckelanvändning, partiell kedja som icke-dödliga fel; Premissen är i det här fallet att certifikatet bara är ett kuvert för ett nyckelpar – säkerheten ligger i det faktum att klusterägaren har satt in platsmått för att skydda den privata nyckeln.

Följande utdrag från ett klustermanifest är ett exempel på en sådan uppsättning tumavtrycksbaserade valideringsregler:

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

Var och en av posterna ovan refererar till en specifik identitet enligt beskrivningen tidigare. varje post gör det också möjligt att ange flera värden, som kommaavgränsad lista med strängar. I det här exemplet, när du har verifierat inkommande autentiseringsuppgifter, presentatör för ett certifikat med SHA-1 tumavtryck 'd5ec... 4264 kommer att beviljas rollen "administratör". omvänt autentiserar en anropare med certifikatet '7c8f... 01b0 beviljas en användarroll, begränsad till främst skrivskyddade åtgärder. En inkommande anropare som visar ett certifikat vars tumavtryck antingen är "abcd... 1234 eller "ef01... 5678" accepteras som en peer-nod i klustret. Slutligen förväntar sig en klient som ansluter till en hanteringsslutpunkt i klustret att tumavtrycket för servercertifikatet är "ef01... 5678'.

Som tidigare nämnts gör Service Fabric bestämmelser för att acceptera utgångna certifikat. Anledningen är att certifikaten har en begränsad livslängd, och när de deklareras med tumavtryck (som refererar till en specifik certifikatinstans) resulterar det antingen i att ett certifikat upphör att gälla att ansluta till klustret eller en fullständig kollaps av klustret. Det är alltför lätt att glömma eller försumma att rotera ett tumavtrycksfäst certifikat, och tyvärr är återställningen från en sådan situation svår.

Därför kan klusterägaren uttryckligen ange att självsignerade certifikat som deklarerats med tumavtryck ska betraktas som giltiga enligt följande:

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

Det här beteendet gäller inte certifikat som utfärdats av certifikatutfärdare. Om så är fallet kan ett återkallat, känt för att vara komprometterat utgånget certifikat bli "giltigt" så snart det inte längre finns med i certifikatutfärdarlistan för återkallade certifikat och därmed utgöra en säkerhetsrisk. Med självsignerade certifikat anses klusterägaren vara den enda part som ansvarar för att skydda certifikatets privata nyckel, vilket inte är fallet med CA-utfärdade certifikat – klusterägaren kanske inte känner till hur eller när certifikatet förklarades komprometterat.

Vanliga namnbaserade certifikatverifieringsdeklarationer

Vanliga namnbaserade deklarationer har något av följande formulär:

  • ämnesnamn (endast)
  • ämnesnamn med utfärdarens fästning

Låt oss först överväga ett utdrag från ett klustermanifest som illustrerar båda deklarationsformaten:

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Deklarationerna refererar till server- respektive klusteridentiteterna. Observera att de CN-baserade deklarationerna har egna avsnitt i klustermanifestet, åtskilda från standarden "Säkerhet". I båda deklarationerna representerar namnet det unika ämnesnamnet för certifikatet, och fältet Värde representerar den förväntade utfärdaren enligt följande:

  • I det första fallet anger deklarationen att det gemensamma namnelementet i det unika ämnet för servercertifikatet förväntas matcha strängen "server.demo.system.servicefabric.azure-int"; Det tomma fältet Värde anger förväntningen att roten i certifikatkedjan är betrodd på den nod/dator där servercertifikatet verifieras. i Windows innebär det att certifikatet kan länkas till något av de certifikat som är installerade i arkivet "Betrodd rotcertifikatutfärdare".
  • I det andra fallet anger deklarationen att presentatören för ett certifikat godkänns som en peer-nod i klustret om certifikatets gemensamma namn matchar strängen "cluster.demo.system.servicefabric.azure-int" och tumavtrycket för certifikatets direktutfärdare matchar en av kommaavgränsade poster i fältet Värde. (Den här regeltypen kallas i vardagligt tal för "common name with issuer pinning".)

I båda fallen skapas certifikatets kedja och förväntas vara felfri. Det vill: återkallningsfel, partiella kedja eller tids-ogiltiga förtroendefel anses vara allvarliga och certifikatverifieringen misslyckas. Om du fäster utfärdarna kommer statusen "ej betrodd rot" att övervägas som ett icke-allvarligt fel. Trots utseendet är detta en striktare form av validering, eftersom det gör det möjligt för klusterägaren att begränsa uppsättningen auktoriserade/godkända utfärdare till sin egen PKI.

När certifikatkedjan har skapats verifieras den mot en standardprincip för TLS/SSL med det deklarerade ämnet som fjärrnamn. ett certifikat betraktas som en matchning om dess ämnesnamn eller något av dess alternativa ämnesnamn matchar CN-deklarationen från klustermanifestet. Jokertecken stöds i det här fallet och strängmatchningen är skiftlägeskänslig.

(Vi bör klargöra att sekvensen som beskrivs ovan kan köras för varje typ av nyckelanvändning som deklareras av certifikatet. Om certifikatet anger användningen av klientautentiseringsnyckeln skapas och utvärderas kedjan först för en klientroll. Om det lyckas slutförs utvärderingen och valideringen lyckas. Om certifikatet inte har användning av klientautentisering, eller om verifieringen misslyckades, kommer Service Fabric-körningen att skapa och utvärdera kedjan för serverautentisering.)

För att slutföra exemplet illustrerar följande utdrag deklarering av klientcertifikat med eget namn:

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

Deklarationerna ovan motsvarar administratörs- respektive användaridentiteterna. validering av certifikat som deklarerats på det här sättet är exakt enligt beskrivningen i föregående exempel på kluster- och servercertifikat.

Kommentar

Vanliga namnbaserade deklarationer är avsedda att förenkla rotationen och i allmänhet hanteringen av klustercertifikat. Vi rekommenderar dock att du följer följande rekommendationer för att säkerställa fortsatt tillgänglighet och säkerhet för klustret:

  • föredrar att utfärdaren fäster till att förlita sig på betrodda rötter
  • undvik att blanda utfärdare från olika PKIs
  • se till att alla förväntade utfärdare visas i certifikatdeklarationen, en problemmatchningsutfärdare resulterar i en misslyckad validering
  • se till att slutpunkterna för PKI:ns certifikatprincip kan identifieras, vara tillgängliga och tillgängliga – det innebär att AIA-, CRL- eller OCSP-slutpunkterna deklareras på lövcertifikatet och att de är tillgängliga så att certifikatkedjan kan slutföras.

När du binder ihop allt när du tar emot en begäran om en anslutning i ett kluster som skyddas med X.509-certifikat, använder Service Fabric-körningen klustrets säkerhetsinställningar för att verifiera fjärrpartens autentiseringsuppgifter enligt beskrivningen ovan. om det lyckas anses anroparen/fjärrparten vara autentiserad. Om autentiseringsuppgifterna matchar flera valideringsregler ger körningen anroparen den högst privilegierade rollen för någon av de matchade reglerna.

Presentationsregler

I föregående avsnitt beskrevs hur autentisering fungerar i ett certifikatskyddat kluster. I det här avsnittet förklaras hur Själva Service Fabric-körningen identifierar och läser in de certifikat som används för kommunikation i klustret. vi kallar dessa "presentationsregler".

Precis som med verifieringsreglerna anger presentationsreglerna en roll och den associerade autentiseringsdeklarationen, uttryckt antingen med tumavtryck eller eget namn. Till skillnad från valideringsreglerna har vanliga namnbaserade deklarationer inte bestämmelser för att fästa utfärdare. Detta ger större flexibilitet och bättre prestanda. Presentationsreglerna deklareras i avsnittet NodeType i klustermanifestet för varje distinkt nodtyp. inställningarna delas upp från säkerhetsavsnitten i klustret så att varje nodtyp kan ha sin fullständiga konfiguration i ett enda avsnitt. I Azure Service Fabric-kluster är certifikatdeklarationer av nodtyp standard för motsvarande inställningar i avsnittet Säkerhet i definitionen av klustret.

Presentationsdeklarationer för tumavtrycksbaserat certifikat

Som tidigare beskrivits skiljer Service Fabric-körningen mellan dess roll som peer för andra noder i klustret och som server för klusterhanteringsåtgärder. I princip kan de här inställningarna konfigureras tydligt, men i praktiken tenderar de att justeras. För resten av den här artikeln förutsätter vi att inställningarna matchar för enkelhetens skull.

Låt oss överväga följande utdrag från ett klustermanifest:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

Elementet "ClusterCertificate" visar det fullständiga schemat, inklusive valfria parametrar ("X509FindValueSecondary") eller de med lämpliga standardvärden ("X509StoreName"). de andra deklarationerna visar ett förkortat formulär. Klustercertifikatdeklarationen ovan anger att säkerhetsinställningarna för noder av typen "nt1vm" initieras med certifikatet "cc71.. 1984 som primär, och "49e2.. 19d6-certifikat som sekundärt. båda certifikaten förväntas hittas i LocalMachine'My'-certifikatarkivet (eller linux-motsvarande sökväg, var/lib/sfcerts).

Vanliga namnbaserade certifikatpresentationsdeklarationer

Nodtypcertifikaten kan också deklareras med ämnesnamnet, enligt exemplet nedan:

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

För båda typerna av deklaration läser en Service Fabric-nod konfigurationen vid start, letar upp och läser in de angivna certifikaten och sorterar dem i fallande ordning efter attributet NotBefore. Utgångna certifikat ignoreras och det första elementet i listan väljs som klientautentiseringsuppgifter för alla Service Fabric-anslutningar som görs av den här noden. (I själva verket föredrar Service Fabric det senast utfärdade certifikatet.)

Kommentar

Före version 7.2.445 (7.2 CU4) valde Service Fabric det längsta utgångna certifikatet (certifikatet med den längsta egenskapen NotAfter)

Observera att för vanliga namnbaserade presentationsdeklarationer betraktas ett certifikat som en matchning om dess ämnesnamn är lika med fältet X509FindValue (eller X509FindValueSecondary) i deklarationen som en skiftlägeskänslig, exakt strängjämförelse. Detta står i kontrast till valideringsreglerna, som stöder jokerteckenmatchning, samt skiftlägesokänsliga strängjämförelser.

Diverse konfigurationsinställningar för certifikat

Tidigare nämndes att säkerhetsinställningarna för ett Service Fabric-kluster också tillåter att beteendet för autentiseringskoden ändras subtilt. Även om artikeln om Service Fabric-klusterinställningar representerar den omfattande och mest aktuella listan med inställningar, expanderar vi innebörden av några få av säkerhetsinställningarna här för att slutföra den fullständiga exponeringen för certifikatbaserad autentisering. För varje inställning förklarar vi avsikten, standardvärdet/beteendet, hur den påverkar autentiseringen och vilka värden som är acceptabla.

Som nämnts innebär certifikatverifiering alltid att skapa och utvärdera certifikatets kedja. För CERTIFIKATutfärdade certifikat innebär det här till synes enkla anropet för OS API vanligtvis flera utgående anrop till olika slutpunkter för den utfärdande PKI:n, cachelagring av svar och så vidare. Med tanke på förekomsten av certifikatverifieringsanrop i ett Service Fabric-kluster kan eventuella problem i PKI:s slutpunkter leda till minskad tillgänglighet för klustret eller en fullständig uppdelning. Även om utgående anrop inte kan ignoreras (se avsnittet Vanliga frågor och svar nedan för mer information om detta), kan följande inställningar användas för att maskera valideringsfel som orsakas av misslyckade CRL-anrop.

  • CrlCheckingFlag – under avsnittet "Säkerhet" konverteras strängen till UINT. Värdet för den här inställningen används av Service Fabric för att maskera statusfel för certifikatkedjan genom att ändra beteendet för kedjebyggande. Den skickas till Win32 CryptoAPI CertGetCertificateChain-anropet som parametern "dwFlags" och kan ställas in på valfri giltig kombination av flaggor som accepteras av funktionen. Värdet 0 tvingar Service Fabric-körningen att ignorera eventuella förtroendestatusfel – detta rekommenderas inte eftersom dess användning skulle utgöra en betydande säkerhetsexponering. Standardvärdet är 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT).

När du ska använda: för lokal testning, med självsignerade certifikat eller utvecklarcertifikat som inte är helt formade/inte har någon lämplig infrastruktur för offentlig nyckel för att stödja certifikaten. Kan också användas som åtgärd i luftgapade miljöer under övergången mellan PKIs.

Så här använder du: Vi tar ett exempel som tvingar återkallningskontroll att endast komma åt cachelagrade URL:er. Antar:

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

blir deklarationen i klustermanifestet:

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError – under avsnittet "Säkerhet" booleskt värde med standardvärdet "false". Representerar en genväg för att förhindra att en "återkallning offline"-kedja skapar felstatus (eller en efterföljande status för valideringsfel för kedjeprincip).

När du ska använda: lokal testning eller med utvecklarcertifikat som inte backas upp av en korrekt PKI. Använd som åtgärd i luftgapade miljöer eller när PKI:en är känd för att vara otillgänglig.

Så här använder du:

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

Andra viktiga inställningar (alla under avsnittet "Säkerhet"):

  • AcceptExpiredPinnedClusterCertificate – beskrivs i avsnittet som är dedikerat till tumavtrycksbaserad certifikatverifiering; tillåter godkännande av självsignerade klustercertifikat som har upphört att gälla.
  • CertificateExpirySafetyMargin – intervall uttryckt i minuter före certifikatets NotAfter-tidsstämpel och under vilken certifikatet anses vara i riskzonen för förfallotid. Service Fabric övervakar klustercertifikat och genererar regelbundet hälsorapporter om återstående tillgänglighet. Inom säkerhetsintervallet förhöjs dessa hälsorapporter till "varningsstatus". Standardvärdet är 30 dagar.
  • CertificateHealthReportingInterval – styr frekvensen för hälsorapporter om återstående tids giltighet för klustercertifikat. Rapporter genereras bara en gång per det här intervallet. Värdet uttrycks i sekunder, med standardvärdet 8 timmar.
  • EnforcePrevalidationOnSecurityChanges – booleskt, styr beteendet för klusteruppgradering vid identifiering av ändringar i säkerhetsinställningarna. Om värdet är true försöker klusteruppgraderingen se till att minst ett av certifikaten som matchar någon av presentationsreglerna kan godkänna en motsvarande verifieringsregel. Förvalideringen utförs innan de nya inställningarna tillämpas på någon nod, men körs bara på noden som är värd för den primära repliken av Cluster Manager-tjänsten när uppgraderingen initieras. När det här skrivs har inställningen standardvärdet "false" och kommer att anges till "true" för nya Azure Service Fabric-kluster med en körningsversion som börjar med 7.1.

Scenario från slutpunkt till slutpunkt (exempel)

Vi har tittat på presentationsregler, valideringsregler och justeringsflaggor, men hur fungerar allt detta tillsammans? I det här avsnittet går vi igenom två exempel från slutpunkt till slutpunkt som visar hur säkerhetsinställningarna kan användas för säkra klusteruppgraderingar. Observera att detta inte är avsett att vara en omfattande avhandling om korrekt certifikathantering i Service Fabric, leta efter en kompletterande artikel om det ämnet.

Separationen av presentations- och valideringsregler utgör den uppenbara frågan (eller oron) om huruvida de kan skilja sig åt och vilka konsekvenserna skulle bli. Det är faktiskt möjligt att en nods val av ett autentiseringscertifikat inte klarar verifieringsreglerna för en annan nod. I själva verket är den här avvikelsen den främsta orsaken till autentiseringsrelaterade incidenter. Samtidigt gör separationen av dessa regler att ett kluster kan fortsätta att fungera under en uppgradering som ändrar klustrets säkerhetsinställningar. Tänk på att genom att först utöka verifieringsreglerna som ett första steg konvergerar alla klusternoder på de nya inställningarna samtidigt som de aktuella autentiseringsuppgifterna används.

Kom ihåg att i ett Service Fabric-kluster fortsätter en uppgradering genom (upp till 5) "uppgraderingsdomäner" eller UD:er. Endast noder i den aktuella UD:en uppgraderas/ändras vid en viss tidpunkt, och uppgraderingen fortsätter endast till nästa UD om klustrets tillgänglighet tillåter det. (Se Service Fabric-klusteruppgraderingar och andra artiklar om samma ämne för mer information.) Certifikat-/säkerhetsändringar är särskilt riskfyllda eftersom de kan isolera noder från klustret eller lämna klustret vid gränsen för kvorumförlust.

Vi använder följande notation för att beskriva en nods säkerhetsinställningar:

Nk: {P:{TP=A}, V:{TP=A}}, där:

  • "Nk" representerar en nod i uppgraderingsdomänen k
  • "P" representerar nodens aktuella presentationsregler (förutsatt att vi endast refererar till klustercertifikat);
  • "V" representerar nodens aktuella valideringsregler (endast klustercertifikat)
  • "TP=A" representerar en tumavtrycksbaserad deklaration (TP), där "A" är ett tumavtryck för certifikat
  • "CN=B" representerar en gemensam namnbaserad deklaration (CN), där "B" är certifikatets ämnesnamn

Rotera ett klustercertifikat som deklarerats med tumavtryck

I följande sekvens beskrivs hur en uppgradering i två steg kan användas för att på ett säkert sätt introducera ett sekundärt klustercertifikat som deklareras med tumavtryck. första fasen introducerar den nya certifikatdeklarationen i valideringsreglerna, och den andra fasen introducerar den i presentationsreglerna:

  • initialt tillstånd: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} – klustret är i vila, alla noder delar en gemensam konfiguration
  • när du har slutfört uppgraderingsdomänen 0: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} – noder i UD0 visar certifikat A och accepterar certifikat A eller B; alla andra noder finns och accepterar endast certifikat A
  • när du har slutfört den senaste uppgraderingsdomänen: N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} – alla noder presenterar certifikat A, alla noder accepterar antingen certifikat A eller B

Nu är klustret återigen i balans och den andra fasen av säkerhetsinställningarna för uppgradering/ändring kan påbörjas:

  • när du har slutfört uppgraderingsdomänen 0: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A}, V:{TP=A, TP=B}} – noder i UD0 börjar presentera B, som accepteras av andra noder i klustret.
  • när du har slutfört den senaste uppgraderingsdomänen: N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ... Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} – alla noder har växlat till att presentera certifikat B. Certifikat A kan nu dras tillbaka/tas bort från klusterdefinitionen med en efterföljande uppsättning uppgraderingar.

Konvertera ett kluster från tumavtryck till vanliga namnbaserade certifikatdeklarationer

På samma sätt följer en ändring av typen av certifikatdeklaration (från tumavtryck till gemensamt namn) samma mönster som ovan. Observera att verifieringsregler tillåter att certifikaten för en viss roll deklareras med både tumavtryck och gemensamt namn i samma klusterdefinition. Däremot tillåter presentationsreglerna endast en form av deklaration. För övrigt är den säkra metoden för att konvertera ett klustercertifikat från tumavtryck till gemensamt namn att först introducera det avsedda målcertifikatet med tumavtryck och sedan ändra deklarationen till ett gemensamt namnbaserat certifikat. I följande exempel förutsätter vi att tumavtrycket "A" och det vanliga ämnesnamnet "B" refererar till samma certifikat.

  • initialt tillstånd: N0 = {P:{TP=A}, V:{TP=A}}, ... Nk = {P:{TP=A}, V:{TP=A}} – klustret är i vila, alla noder delar en gemensam konfiguration, där A är det primära certifikatets tumavtryck
  • när du har slutfört uppgraderingsdomänen 0: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A}} – noder i UD0 visar certifikat A och accepterar certifikat med antingen tumavtryck A eller eget namn B; alla andra noder finns och accepterar endast certifikat A
  • när du har slutfört den senaste uppgraderingsdomänen: N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} – alla noder presenterar certifikat A, alla noder skulle acceptera antingen certifikat A (TP) eller B (CN)

Nu kan vi fortsätta med att ändra presentationsreglerna med en efterföljande uppgradering:

  • när du har slutfört uppgraderingsdomänen 0: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{TP=A}, V:{TP=A, CN=B}} – noder i UD0 visar certifikat B som hittas av CN och accepterar certifikat med antingen tumavtryck A eller eget namn B; alla andra noder som finns och accepterar endast certifikat A, valda med tumavtryck
  • när du har slutfört den senaste uppgraderingsdomänen: N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ... Nk = {P:{CN=B}, V:{TP=A, CN=B}} – alla noder presenterar certifikat B som hittas av CN, alla noder skulle acceptera antingen certifikat A (TP) eller B (CN)

Slutförandet av fas 2 markerar också konverteringen av klustret till vanliga namnbaserade certifikat. de tumavtrycksbaserade valideringsdeklarationerna kan tas bort i en efterföljande klusteruppgradering.

Kommentar

I Azure Service Fabric-kluster samordnas de arbetsflöden som visas ovan av Service Fabric-resursprovidern. Klusterägaren ansvarar fortfarande för att etablera certifikat i klustret enligt angivna regler (presentation eller validering) och uppmanas att utföra ändringar i flera steg.

I en separat artikel tar vi upp ämnet för att hantera och etablera certifikat i ett Service Fabric-kluster.

Felsökning och vanliga frågor och svar

Det är inte lätt att felsöka autentiseringsrelaterade problem i Service Fabric-kluster, men vi hoppas att följande tips kan hjälpa. Det enklaste sättet att påbörja undersökningar är att undersöka Service Fabric-händelseloggarna på noderna i klustret , inte nödvändigtvis bara de som visar symtom, utan även noder som är igång men inte kan ansluta till en av sina grannar. I Windows loggas händelser av betydelse vanligtvis under kanalerna "Program- och tjänstloggar\Microsoft-ServiceFabric\Admin" respektive "Operational". Ibland kan det vara bra att aktivera CAPI2-loggning för att samla in mer information om certifikatvalidering, hämtning av CRL/CTL osv. (Kom ihåg att inaktivera den när du har slutfört repro, det kan vara ganska utförligt.)

Vanliga symptom som visar sig i ett kluster som har autentiseringsproblem är:

  • noder är nere/cyklar
  • anslutningsförsök avvisas
  • anslutningsförsök är tidsgränsen ute

Var och en av symtomen kan orsakas av olika problem, och samma rotorsak kan visa olika manifestationer; Därför listar vi bara ett litet urval av vanliga problem med rekommendationer för att åtgärda dem.

  • Noder kan utbyta meddelanden men kan inte ansluta. En möjlig orsak till att anslutningsförsök avslutas är felet "certifikatet matchas inte" – en av parterna i en Service Fabric-to-Service Fabric-anslutning presenterar ett certifikat som inte uppfyller mottagarens valideringsregler. Kan åtföljas av något av följande fel:

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    För att diagnostisera/undersöka ytterligare: på var och en av noderna som försöker ansluta, avgör du vilket certifikat som visas; granska certifikatet och prova att emulera verifieringsreglerna (kontrollera om tumavtrycket eller likheten med det gemensamma namnet finns, kontrollera tumavtrycken för utfärdaren om det anges).

    En annan vanlig tillhörande felkod kan vara:

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    I det här fallet deklareras certifikatet med eget namn och något av följande gäller:

    • utfärdarna inte är fästa och rotcertifikatet är inte betrott, eller
    • utfärdarna är fästa men deklarationen innehåller inte tumavtrycket för den direkta utfärdaren av det här certifikatet

  • En nod är igång, men kan inte ansluta till andra noder. andra noder tar inte emot inkommande trafik från den nod som misslyckas. I det här fallet är det möjligt att certifikatinläsningen misslyckas på den lokala noden. Leta efter följande fel:

    • certifikatet hittades inte – se till att de certifikat som deklareras i presentationsreglerna kan matchas av innehållet i certifikatarkivet LocalMachine\My (eller enligt angivet). Möjliga orsaker till fel kan vara:

      • ogiltiga tecken i tumavtrycksdeklarationen
      • certifikatet är inte installerat
      • certifikatet har upphört att gälla
      • common-name-deklarationen innehåller prefixet "CN="
      • deklarationen anger ett jokertecken och det finns ingen exakt matchning i certifikatarkivet (deklaration: CN=*.mydomain.com, faktiskt certifikat: CN=server.mydomain.com)

    • okända autentiseringsuppgifter – anger antingen en privat nyckel som saknas som motsvarar certifikatet, vanligtvis tillsammans med felkoden:

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      Kontrollera att det finns en privat nyckel för att åtgärda problemet. kontrollera att SFAdmins beviljas "read|execute"-åtkomst till den privata nyckeln.

    • dålig providertyp – anger ett CNG-certifikat (Crypto New Generation) ("Microsoft Software Key Storage Provider"); För närvarande stöder Service Fabric endast CAPI1-certifikat. Åtföljs vanligtvis av felkod:

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      Du kan åtgärda problemet genom att återskapa klustercertifikatet med hjälp av en CAPI1-provider (t.ex. "Microsoft Enhanced RSA and AES Cryptographic Provider"). Mer information om kryptoprovidrar finns i Förstå kryptografiska providers