Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

gRPC-Services konfigurieren

Konfigurieren Sie den gRPC-Server so, dass ein Client gRPC-Dienste auf dem Netzwerkgerät verwenden kann, einschließlich: gRPC-gNOI-Dienste (Network Operations Interface), gRPC-gNMI-Dienste (Network Management Interface) und gRPC-Routing-Informationsbasis-Schnittstellendienste (gRIBI).

In diesem Thema wird erläutert, wie gRPC-Dienste auf Junos-Geräten konfiguriert werden, einschließlich der Optionen für die Authentifizierung und der Konfiguration der einzelnen Optionen. Bevor der Server und der Client eine gRPC-Sitzung einrichten können, müssen Sie die in den folgenden Abschnitten erläuterten Anforderungen erfüllen:

Authentifizierung und Autorisierung für gRPC-basierte Services verstehen

Die Schnittstellen gNMI, gNOI und gRIBI verwenden das gRPC Remote Procedure Call-Framework für den Transport. Der gRPC-Server wird auf dem Netzwerkgerät ausgeführt und wartet auf Verbindungsanforderungen an einem angegebenen Port. Die gRPC-Clientanwendung wird auf einem Remotenetzwerkmanagementsystem (NMS) ausgeführt und richtet einen gRPC-Kanal mit dem Server auf dem angegebenen Host und Port ein. Der Client führt RPCs über die SSL-verschlüsselte gRPC-Sitzung aus, um Netzwerkservicevorgänge durchzuführen. Abbildung 1 zeigt eine einfache Verbindung zwischen einem gRPC-Client und einem Server.

Abbildung 1: Interaktion gRPC Server and Client Interaction zwischen gRPC-Server und Client

gRPC-Kanäle verwenden Kanalanmeldeinformationen, um die Authentifizierung zwischen dem Server und dem Client zu verarbeiten. Standardkanalanmeldeinformationen verwenden digitale X.509-Zertifikate zur Authentifizierung des Servers und des Clients. Ein digitales Zertifikat bietet eine Möglichkeit, Benutzer über einen vertrauenswürdigen Drittanbieter zu authentifizieren, der als Zertifizierungsstelle oder Zertifizierungsstelle (CA) bezeichnet wird. Die CA überprüft die Identität eines Zertifikatsinhabers und "signiert" das Zertifikat, um zu bestätigen, dass es nicht gefälscht oder verändert wurde. Der X.509-Standard definiert das Format für das Zertifikat. Digitale Zertifikate können verwendet werden, um durch Zertifikatsvalidierung eine sichere Verbindung zwischen zwei Endgeräten herzustellen. Um einen gRPC-Kanal einzurichten, muss jedes Endgerät (Gerät oder Anwendung), für das eine Authentifizierung erforderlich ist, ein X.509-Zertifikat im Exchange bereitstellen.

Junos-Geräte unterstützen sowohl die reine Server-Authentifizierung als auch die gegenseitige Authentifizierung für SSL- und TLS-basierte gRPC-Sitzungen. Wenn die reine Server-Authentifizierung konfiguriert ist, stellt der Server sein Zertifikat mit öffentlichem Schlüssel bereit, wenn der Kanal eingerichtet wird. Der Client verwendet das Root-CA-Zertifikat des Servers, um den Server zu authentifizieren. Wenn die gegenseitige Authentifizierung konfiguriert ist, stellt der Client auch sein Zertifikat bereit, wenn er eine Verbindung mit dem Server herstellt, und der Server validiert das Zertifikat. Wenn die Zertifikatsüberprüfung erfolgreich ist, kann der Client Aufrufe tätigen. Es wird empfohlen, die gegenseitige Authentifizierung zu konfigurieren und von einer CA signierte Zertifikate für die höchste Sicherheit zu verwenden, obwohl selbstsignierte Zertifikate akzeptiert werden.

Eine Public-Key-Infrastructure (PKI) unterstützt die Verteilung und Identifizierung von öffentlichen Verschlüsselungsschlüsseln, sodass Benutzer sowohl Daten über Netzwerke wie das Internet sicher austauschen als auch die Identität der anderen Partei überprüfen können. Für gRPC-basierte Services muss die Junos PKI das Zertifikat für das lokale Gerät enthalten, das als gRPC-Server fungiert. Wenn Sie die gegenseitige Authentifizierung verwenden, muss die Junos-PKI auch die Root-CA-Zertifikate enthalten, die für die Validierung der Zertifikate aller gRPC-Clients erforderlich sind, die eine Verbindung mit dem Gerät herstellen.

Tabelle 1 beschreibt die allgemeinen Anforderungen für die reine Server-Authentifizierung und die gegenseitige Authentifizierung, wenn ein gRPC-Client eine Verbindung mit dem Gerät herstellt, um gRPC-basierte Services auszuführen. Das Zertifikat des gRPC-Servers muss entweder den Hostnamen des Servers im Feld Allgemeiner Name (CN) oder die IP-Adresse des Servers im Feld Alternativer Antragstellername (subjectAltName oder SAN) IP-Adresse definieren. Die Clientanwendung muss denselben Wert verwenden, um die Verbindung mit dem Server herzustellen. Wenn das Zertifikat das Feld "SubjectAltName"-IP-Adresse definiert, wird das Feld "Allgemeiner Name" während der Authentifizierung ignoriert.

Tabelle 1: Anforderungen für reine Serverauthentifizierung und gegenseitige Authentifizierung für gRPC-Sitzungen
Anforderungen Nur Server-Authentifizierung Gegenseitige Authentifizierung
Zertifikate

Der Server muss über ein X.509-Zertifikat mit öffentlichem Schlüssel verfügen.

Wenn der Client eine Verbindung mit der IP-Adresse des Servers anstelle des Hostnamens herstellt, muss das Zertifikat des Servers das SAN-IP-Adresserweiterungsfeld subjectAltName (SAN) mit der IP-Adresse des Servers enthalten.

Der Server und der Client müssen jeweils über ein X.509-Zertifikat mit öffentlichem Schlüssel verfügen.

Wenn der Client eine Verbindung mit der IP-Adresse des Servers anstelle des Hostnamens herstellt, muss das Zertifikat des Servers das SAN-IP-Adresserweiterungsfeld subjectAltName (SAN) mit der IP-Adresse des Servers enthalten.
Junos PKI

Das lokale Zertifikat des Servers muss in die Junos PKI geladen werden.

Das lokale Zertifikat des Servers und das Root-CA-Zertifikat jedes Clients müssen in die Junos-PKI geladen werden.
Channel-Anmeldeinformationen

Der Client muss das Root-CA-Zertifikat des Servers übergeben, wenn der gRPC-Kanal eingerichtet wird.

Der Client muss sein Zertifikat und seinen Schlüssel sowie das Root-CA-Zertifikat des Servers übergeben, wenn der gRPC-Kanal eingerichtet ist.

Kanalanmeldeinformationen werden an den gRPC-Kanal angefügt und ermöglichen der Clientanwendung den Zugriff auf den Dienst. Aufrufanmeldeinformationen hingegen sind an einen bestimmten Dienstvorgang (RPC-Anforderung) angefügt und liefern Informationen über die Person, die die Clientanwendung verwendet. Die Anmeldeinformationen für Anrufe werden pro Anforderung gesendet, d. h. für jeden RPC-Aufruf. Um gRPC-basierte Vorgänge auf Junos-Geräten auszuführen, müssen Sie in der Anforderung Anmeldeinformationen für den Aufruf angeben. Der Benutzer muss entweder über ein lokal auf dem Gerät definiertes Benutzerkonto verfügen, oder der Benutzer muss von einem TACACS+-Server authentifiziert werden, der den Benutzer dann einem Benutzervorlagenkonto zuordnet, das lokal auf dem Gerät definiert ist. Sie können die Anmeldeinformationen für den Anruf (Benutzername und Kennwort) im Argument des metadata RPC angeben. Wenn die Authentifizierung erfolgreich ist, führt das Junos-Gerät die RPC-Anforderung mit den Kontoberechtigungen des angegebenen Benutzers aus.

Hinweis:

Alternativ zur Übergabe von Anmeldeinformationen für jeden auf einem Junos-Gerät ausgeführten RPC können Sie die Juniper Extension Toolkit jnx_authentication_service API verwenden, um sich zu Beginn der gRPC-Sitzung einmal bei dem Gerät anzumelden, und alle nachfolgenden RPCs, die im Kanal ausgeführt werden, werden authentifiziert. Sie können die IDL-Bibliothek des JET-Clients von der Download-Site von Juniper Networks herunterladen.

Standardmäßig autorisieren Junos-Geräte einen authentifizierten gRPC-Client, alle gRPC-RPCs auszuführen. Sie können optional die Anmeldeklasse eines gRPC-Benutzers so konfigurieren, dass bestimmte gRPC-RPCs explizit zugelassen oder verweigert werden. Um die RPCs anzugeben, konfigurieren Sie die allow-grpc-rpc-regexps and-Anweisungen deny-grpc-rpc-regexps und definieren reguläre Ausdrücke, die den RPCs entsprechen. Weitere Informationen finden Sie unter Konfigurieren der gRPC-RPC-Autorisierung .

Abrufen von X.509-Zertifikaten

Eine gRPC-Sitzung verwendet X.509-Zertifikate mit öffentlichem Schlüssel, um den gRPC-Server und -Client zu authentifizieren. Für die reine Server-Authentifizierung muss der gRPC-Server über ein Zertifikat verfügen. Für die gegenseitige Authentifizierung müssen sowohl der gRPC-Server als auch der Client über Zertifikate verfügen. Die Voraussetzungen für die Zertifikate sind:

  • Das Zertifikat kann von einer CA signiert oder selbstsigniert werden.

  • Das Zertifikat muss PEM-codiert sein.

  • Das Zertifikat des gRPC-Servers muss entweder den Hostnamen des gRPC-Servers im Feld Allgemeiner Name (CN) oder die IP-Adresse des gRPC-Servers im Feld SubjectAltName (SAN) IP-Adresse definieren. Der gRPC-Client muss denselben Wert verwenden, um die Verbindung zum Server herzustellen. Wenn das Zertifikat die IP-Adresse "SubjectAltName" definiert, wird das Feld "Allgemeiner Name" während der Authentifizierung ignoriert.

So verwenden Sie OpenSSL, um das Zertifikat des gRPC-Servers abzurufen:

  1. Generieren Sie einen privaten Schlüssel, und geben Sie die Schlüssellänge in Bits an.
  2. Wenn der gRPC-Client eine Verbindung mit der IP-Adresse des gRPC-Servers herstellt, aktualisieren Sie die Datei openssl.cnf oder eine entsprechende Konfigurationsdatei, um die subjectAltName=IP Erweiterung mit der IP-Adresse des gRPC-Servers zu definieren.
  3. Generieren Sie eine Zertifikatsignieranforderung (Certificate Signing Request, CSR), die den öffentlichen Schlüssel der Entität und Informationen zu ihrer Identität enthält.

    Alternativ können Sie die CSR-Informationen in einem einzigen Befehl bereitstellen, z. B.:

  4. Generieren Sie das Zertifikat, indem Sie einen der folgenden Schritte ausführen:

    • Senden Sie die CSR an eine CA, um ein X.509-Zertifikat anzufordern, und stellen Sie die Konfigurationsdatei bereit, um zusätzliche Erweiterungen einzuschließen.

    • Signieren Sie die CSR mit einer CA, um das Zertifikat zu generieren, und fügen Sie die -extfile Option hinzu, wenn Sie auf Ihre Konfigurationsdatei und Erweiterungen verweisen müssen.

    • Signieren Sie die CSR mit dem Serverschlüssel, um ein selbstsigniertes Zertifikat zu generieren, und fügen Sie die -extfile Option hinzu, wenn Sie auf Ihre Konfigurationsdatei und Erweiterungen verweisen müssen.

  5. Stellen Sie sicher, dass das Feld "Allgemeiner Name" (CN) und die Erweiterungen des Zertifikats, falls angegeben, korrekt sind.

Wiederholen Sie für die gegenseitige Authentifizierung die vorherigen Schritte mit den Informationen für den gRPC-Client, um den Schlüssel und das Zertifikat des Clients zu generieren. Für das Clientzertifikat ist das Feld SAN-IP-Erweiterung nicht erforderlich.

Laden des lokalen Zertifikats des gRPC-Servers in die Junos PKI

Das Netzwerkgerät, auf dem der gRPC-Server ausgeführt wird, muss über ein X.509-Zertifikat verfügen, das das Gerät für gRPC-Clients identifiziert. Um gRPC-basierte Services auf dem Junos-Gerät auszuführen, müssen Sie das Zertifikat mit dem öffentlichen Schlüssel und den Schlüssel für das lokale Netzwerkgerät in die Junos PKI laden. Nachdem Sie das Zertifikat geladen und die Erstkonfiguration durchgeführt haben, können gRPC-Clients einen beliebigen Microservice verwenden, um das Zertifikat zu aktualisieren. Beispielsweise kann ein gRPC-Client den gNOI-Dienst CertificateManagement verwenden, um ein neues Zertifikat zu installieren oder ein vorhandenes Zertifikat zu ersetzen.

So laden Sie das Zertifikat und den Schlüssel des lokalen Geräts in die PKI:

  1. Laden Sie das Zertifikat und den Schlüssel für das Gerät, das als gRPC-Server fungiert, auf dieses Gerät herunter.
  2. Definieren Sie im Betriebsmodus eine Kennung, und laden Sie das Zertifikat und den Schlüssel des lokalen Geräts in die PKI.

    Zum Beispiel:

  3. (Optional) Überprüfen Sie, ob das Zertifikat in der PKI-Datenbank vorhanden ist.

gRPC-Services aktivieren

gRPC-basierte Services verwenden eine API-Verbindungseinstellung, die auf der Secure Socket Layer (SSL)- oder Transportschicht Sicherheit (TLS)-Technologie basiert. Für diese Verbindungen müssen Sie ein lokales Zertifikat angeben, das den gRPC-Server identifiziert.

Nachdem Sie gRPC-Dienste aktiviert und ein lokales Zertifikat angegeben haben, verwendet das Netzwerkgerät die reine Server-Authentifizierung. Anschließend können Sie optional die gegenseitige Authentifizierung konfigurieren, indem Sie die unter Konfigurieren der gegenseitigen (bidirektionalen) Authentifizierung für gRPC-Dienste beschriebenen Schritte ausführen.

Sie können Ihr Netzwerkgerät für gRPC-Dienste konfigurieren und das lokale Zertifikat, das für die Server-Authentifizierung verwendet wird, auf einer der folgenden Hierarchieebenen angeben:

  • [edit system services http servers]– Verwenden Sie diese Anweisungshierarchie, um einen oder mehrere gRPC-Server zu konfigurieren, die verschiedene Gruppen von Services auf eindeutigen Ports hosten. Darüber hinaus kann jeder Server unterschiedliche Überwachungsadressen, Zertifikate und Routinginstanzen unterstützen.

  • [edit system services extension-service request-response grpc ssl]– Verwenden Sie diese Anweisungshierarchie, wenn Sie nur einen einzigen gRPC-Server benötigen, der alle gRPC-Services auf derselben Überwachungsadresse und demselben Port unterstützt.

Um das Gerät für gRPC-Dienste zu konfigurieren, befolgen Sie die Anweisungen für die Hierarchieebene, die den Anforderungen Ihrer Umgebung entspricht.

[edit system services http servers]

So konfigurieren Sie einen oder mehrere gRPC-Server auf Hierarchieebene [edit system services http servers] :

  1. Navigieren Sie zur Hierarchieebene des gRPC-Servers, und geben Sie einen Bezeichner für den Server an.

    Zum Beispiel:

  2. Konfigurieren Sie den Port, der für die gRPC-Dienste verwendet werden soll. Der Port muss für jeden gRPC-Server eindeutig sein.

    Zum Beispiel:

  3. Konfigurieren Sie die gRPC-Dienste, die von diesem Server gehostet werden.

    In diesem Beispiel hostet der Server gNMI-Services und gNOI-Services.

  4. Geben Sie das lokale Zertifikat an, das den Server für einen Client identifiziert.

    Geben Sie die Kennung für das lokale Zertifikat ein, das Sie zuvor mit dem request security pki local-certificate load Befehl Betriebsmodus in die Junos PKI geladen haben.

    Im folgenden Beispiel wird das lokale Zertifikat gnoi-serverkonfiguriert:

  5. (Optional) Geben Sie die IPv4- oder IPv6-Adresse an, an der der Server auf eingehende Verbindungen wartet.

    Zum Beispiel:

    Hinweis:

    Wenn Sie keine IP-Adresse angeben, wird die Standardadresse :: verwendet, um eingehende Verbindungen zu überwachen.

  6. (Optional) Konfigurieren Sie die für diesen gRPC-Server zu verwendende Routinginstanz, falls sie sich von der Standardroutinginstanz unterscheidet.

    Im folgenden Beispiel wird die mgmt-junos Routing-Instanz verwendet.

  7. (Optional) Konfigurieren Sie die maximale Anzahl von Verbindungen, die dieser gRPC-Server unterstützt.

    Im folgenden Beispiel werden maximal 10 Verbindungen konfiguriert. Der Standardwert ist 5.

  8. Bestätigen Sie die Konfiguration.

Um die gegenseitige Authentifizierung anstelle der reinen Server-Authentifizierung zu konfigurieren, müssen Sie auch die Schritte unter Konfigurieren der gegenseitigen (bidirektionalen) Authentifizierung für gRPC-Dienste ausführen.

[edit system services extension-service request-response grpc ssl]

So konfigurieren Sie einen einzelnen gRPC-Server auf Hierarchieebene [edit system services extension-service request-response grpc ssl] :

  1. Navigieren Sie zu den SSL-basierten API-Verbindungseinstellungen für gRPC-Dienste.

  2. Konfigurieren Sie den Port, der für gRPC-Dienste verwendet werden soll.

    Zum Beispiel:

  3. Geben Sie das lokale Zertifikat an, das den Server für einen Client identifiziert.

    Geben Sie die Kennung für das lokale Zertifikat ein, das Sie zuvor mit dem request security pki local-certificate load Befehl Betriebsmodus in die Junos PKI geladen haben.

    Im folgenden Beispiel wird das lokale Zertifikat gnoi-serverkonfiguriert:

  4. Konfigurieren Sie das Gerät für die Verwendung der PKI-Datenbank für Zertifikate.

  5. Aktivieren Sie das Gerät zum erneuten Laden von Zertifikaten, ohne die gRPC-Sitzung zu beenden.

  6. (Optional) Geben Sie eine IP-Adresse an, auf die eingehende Verbindungen überwacht werden sollen.

    Zum Beispiel:

    Hinweis:

    Wenn Sie keine IP-Adresse angeben, wird die Standardadresse :: verwendet, um eingehende Verbindungen zu überwachen.

  7. (Optional) Konfigurieren Sie die Ablaufverfolgung für Erweiterungsdienste, um eventuell auftretende Probleme zu debuggen.

    Hinweis:

    Um Ablaufverfolgungsdateien von Junos OS Evolved für Erweiterungsdienste anzuzeigen, verwenden Sie die show trace application jsd Befehle und show trace application jsd live Betriebsmodus.

  8. Bestätigen Sie die Konfiguration.

Um die gegenseitige Authentifizierung anstelle der reinen Server-Authentifizierung zu konfigurieren, müssen Sie auch die Schritte unter Konfigurieren der gegenseitigen (bidirektionalen) Authentifizierung für gRPC-Dienste ausführen.

Konfiguration der gegenseitigen (bidirektionalen) Authentifizierung für gRPC-Services

Sie können die gegenseitige (bidirektionale) Authentifizierung für gRPC-Sitzungen konfigurieren, bei der sowohl das Netzwerkgerät als gRPC-Server als auch das NMS als gRPC-Client mithilfe von Zertifikaten authentifiziert werden. Das Junos-Gerät verwendet die vom externen Client bereitgestellten Anmeldeinformationen, um den Client zu authentifizieren und eine Verbindung zu autorisieren.

Sie können die gegenseitige Authentifizierung auf Junos-Geräten mit einer der folgenden Optionen konfigurieren:

  • Konfigurieren Sie die Einstellungen für die gegenseitige Authentifizierung direkt in der Konfiguration.

  • Richten Sie zunächst die reine Server-Authentifizierung ein und verwenden Sie dann den gNOI-Dienst CertificateManagement , um die erforderlichen CA-Zertifikate auf das Gerät zu laden.

Wenn Sie die gegenseitige Authentifizierung direkt in der Gerätekonfiguration konfigurieren, hat die Gerätekonfiguration Vorrang vor allen Setups, die mit den gNOI-Services durchgeführt werden.

Bevor Sie beginnen:

In den folgenden Abschnitten werden die verschiedenen Methoden zum Konfigurieren der gegenseitigen Authentifizierung erläutert. Sie können die Methode verwenden, die für Ihre Umgebung am besten geeignet ist.

Konfigurieren der gegenseitigen Authentifizierung in der Gerätekonfiguration

So konfigurieren Sie die Authentifizierung für den gRPC-Client direkt in der Netzwerkgerätekonfiguration:

  1. Laden Sie das Root-CA-Zertifikat, das zur Überprüfung des Client-Zertifikats verwendet wird, auf das lokale Gerät herunter, das als gRPC-Server fungiert.

  2. Konfigurieren Sie ein CA-Profil für die Root-CA des Clientzertifikats in der [edit security pki] Hierarchie.

    Zum Beispiel:

  3. Bestätigen Sie die Konfiguration.

  4. Laden Sie im Betriebsmodus das Root-CA-Zertifikat, das zur Überprüfung des Client-Zertifikats verwendet wird, in die Junos PKI. Geben Sie den Bezeichner an, den ca-profile Sie in den vorherigen Schritten konfiguriert haben.

    Zum Beispiel:

    Tipp:

    Um ein CA-Zertifikatspaket zu laden, geben Sie den request security pki ca-certificate ca-profile-group load ca-group-name ca-group-name filename bundle-path Befehl ein.

    Wechseln Sie nach dem Laden des Zertifikats in den Konfigurationsmodus, und fahren Sie mit der Konfiguration der gegenseitigen Authentifizierung fort. Sie müssen die gegenseitige Authentifizierung auf derselben Hierarchieebene konfigurieren, auf der Sie Ihren Server konfiguriert haben. Führen Sie die im Abschnitt für Ihre Hierarchieebene beschriebenen Schritte aus.

[HTTP-Server der Systemdienste bearbeiten]

So konfigurieren Sie die gegenseitige Authentifizierung für einen auf Hierarchieebene [edit system services http servers] konfigurierten Server:

  1. Navigieren Sie zu der tls Anweisung unter Ihrer Serverkonfiguration.

    Zum Beispiel:

  2. Aktivieren Sie die gegenseitige Authentifizierung, und geben Sie die Anforderungen für Clientzertifikate an.

    Um beispielsweise die stärkste Authentifizierung anzugeben, die ein Zertifikat und dessen Validierung erfordert, verwenden Sie request-and-require-cert-and-verify, was auch die Standardeinstellung ist.

  3. Geben Sie das CA-Profil an, das zum Überprüfen des Clientzertifikats verwendet wird.

    Das CA-Profil wurde in Schritt 2 der Konfiguration des CA-Profils konfiguriert.

    So geben Sie beispielsweise das CA-Profil mit dem Namen gnoi-clientan:

  4. Bestätigen Sie die Konfiguration.

[System Services extension-service request-response grpc ssl bearbeiten]

So konfigurieren Sie die gegenseitige Authentifizierung für einen auf Hierarchieebene [edit system services extension-service request-response grpc ssl] konfigurierten Server:

  1. Aktivieren Sie die gegenseitige Authentifizierung, und geben Sie die Anforderungen für Clientzertifikate an.

    Um beispielsweise die stärkste Authentifizierung anzugeben, für die ein Zertifikat und dessen Validierung erforderlich sind, verwenden Sie require-certificate-and-verify.

    Hinweis:

    Der Standardwert ist no-certificate. Die anderen Optionen sind: request-certificate, request-certificate-and-verify, require-certificate, . require-certificate-and-verify

    Es wird empfohlen, die no-certificate Option nur in einer Testumgebung zu verwenden.

  2. Geben Sie das CA-Profil an, das zum Überprüfen des Clientzertifikats verwendet wird.

    Das CA-Profil wurde in Schritt 2 der Konfiguration des CA-Profils konfiguriert.

    So geben Sie beispielsweise das CA-Profil mit dem Namen gnoi-clientan:

  3. Bestätigen Sie die Konfiguration.

Konfiguration der gegenseitigen Authentifizierung mit dem gNOI CertificateManagement Service

Sie können den gNOI-Dienst CertificateManagement verwenden, um die gegenseitige Authentifizierung zwischen dem gRPC-Client und dem gRPC-Server einzurichten, anstatt die Einstellungen direkt in der Gerätekonfiguration zu konfigurieren. Sie richten zunächst die reine Server-Authentifizierung ein und verwenden dann die gNOI-Dienst-RPCs CertificateManagement , um die Client-CA-Zertifikate zu laden. Unter Kein Linktitel finden Sie Informationen zum Laden der Zertifikate mit dem gNOI-Dienst CertificateManagement .

Der gRPC-Server unterstützt nur ein globales CA-Zertifikatspaket für gNOI-Dienste. Wenn Sie den gNOI-Dienst CertificateManagement zum Laden des CA-Zertifikatpakets verwenden, verwendet das Gerät implizit die gegenseitige Authentifizierung. Beachten Sie jedoch Folgendes:

  • Der CertificateManagement Dienst lädt das CA-Zertifikatspaket immer mit dem ca-profile-group reservierten Bezeichner gnoi-ca-bundle.

  • Wenn Sie den CertificateManagement Dienst zum Laden des CA-Zertifikatpakets verwenden, verwendet das Gerät implizit die gegenseitige Authentifizierung.

  • Wenn der CertificateManagement Dienst eine Anforderung zum Laden eines neuen CA-Zertifikatpakets sendet, löscht der Server die Zertifikate für das vorherige CA-Bundle vom Gerät und lädt die neuen.

  • Wenn Sie den CertificateManagement Dienst zum Laden eines CA-Zertifikatpakets verwenden und auch die gegenseitige Authentifizierung explizit in der Gerätekonfiguration konfigurieren, haben die konfigurierten Anweisungen Vorrang.

Konfigurieren des Benutzerkontos für gRPC-Dienste

Kanalanmeldeinformationen werden an den gRPC-Kanal angefügt und ermöglichen der Clientanwendung den Zugriff auf den Dienst. Aufrufanmeldeinformationen werden an eine bestimmte RPC-Anforderung angefügt und enthalten Informationen über den Benutzer, der die Clientanwendung verwendet. Sie müssen in jeder RPC-Anforderung Anmeldeinformationen für Anrufe angeben, wofür ein Benutzerkonto für das Netzwerkgerät erforderlich ist. Der Benutzer muss über ein lokal auf dem Netzwerkgerät definiertes Benutzerkonto verfügen, oder der Benutzer muss von einem TACACS+-Server authentifiziert werden, der den Benutzer dann einem Benutzervorlagenkonto zuordnet, das lokal auf dem Gerät definiert ist.

So erstellen Sie ein Benutzerkonto:

  1. Konfigurieren Sie die user Anweisung mit einem eindeutigen Benutzernamen und fügen Sie die class Anweisung ein, um eine Anmeldeklasse anzugeben, die über die Berechtigungen verfügt, die für alle vom Benutzer auszuführenden Aktionen erforderlich sind. Zum Beispiel:
  2. Konfigurieren Sie für lokale Benutzerkonten das Kennwort des Benutzers.

    Sie können das Kennwort für lokale Benutzervorlagenkonten weglassen, da der Benutzer über einen Remote-Authentifizierung-Server authentifiziert wird.

  3. (Optional) Konfigurieren Sie die full-name Anweisung so, dass der Name des Benutzers angegeben wird.
  4. Führen Sie einen Commit für die Konfiguration durch, um das Benutzerkonto auf dem Gerät zu aktivieren.
  5. Wiederholen Sie die vorherigen Schritte auf jedem Netzwerkgerät, auf dem der gRPC-Client RPCs in einer gRPC-Sitzung ausführt.

Konfigurieren der gRPC-RPC-Autorisierung

Standardmäßig autorisieren Junos-Geräte einen authentifizierten gRPC-Client, alle gRPC-RPCs auszuführen. Sie können eine Junos-Anmeldeklasse so konfigurieren, dass gRPC-RPCs explizit zugelassen oder verweigert werden. Um die RPCs anzugeben, konfigurieren Sie die allow-grpc-rpc-regexps and-Anweisungen deny-grpc-rpc-regexps und definieren reguläre Ausdrücke, die den RPCs entsprechen. Wenn in den Zulassungs- und Verweigerungslisten widersprüchliche Ausdrücke vorhanden sind, hat die Verweigerungsliste Vorrang. Wenn ein RPC mit keiner der Listen übereinstimmt, ist der RPC standardmäßig zulässig.

Junos-Geräte verwenden die folgende Syntax zum Angeben von gRPC-RPCs:

Dabei packagesind , , und rpc die Namen, servicedie in der entsprechenden Anweisung in der Proto-Definitionsdatei dieses Dienstes definiert sind. Zum Beispiel:

Sie können mehrere allow-grpc-rpc-regexps und-Anweisungen deny-grpc-rpc-regexps mit einem oder mehreren Ausdrücken konfigurieren. Schließen Sie jeden Ausdruck in Anführungszeichen (" ") ein. Schließen Sie mehrere Ausdrücke in eckige Klammern [ ] ein und trennen Sie die Ausdrücke durch ein Leerzeichen.

So erstellen Sie eine Anmeldeklasse, die die Autorisierung für gRPC-RPCs definiert:

  1. Konfigurieren Sie den Namen und die Berechtigungen der Anmeldeklasse.

    Zum Beispiel:

  2. Konfigurieren Sie innerhalb der Klasse reguläre Ausdrücke für die RPCs, die die Klasse zulässt.

    Die folgende Anweisung lässt beispielsweise den gNMI-RPC Get() und alle gNOI-Service-RPCs System zu.

  3. Konfigurieren Sie reguläre Ausdrücke für die RPCs, die die Klasse ablehnt.

    Die folgenden Anweisungen verweigern beispielsweise den gNMI-RPC Set() und verweigern auch alle RPCs für den gRIBI Dienst sowie den gNOI-Dienst CertificateManagement .

  4. Weisen Sie die Anmeldeklasse den entsprechenden gRPC-Benutzern zu.

    Die folgende Anweisung weist dem grpc-user Benutzer beispielsweise die grpc-operator Klasse zu.

Nachdem Sie die gRPC-Dienste auf dem Netzwerkgerät aktiviert haben, richten Sie das Remote-NMS als gRPC-Client ein. Damit der Client gNOI-Operationen ausführen kann, konfigurieren Sie den Client wie unter Kein Linktitel beschrieben.

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Veröffentlichung
Beschreibung
25.2R1 & 25.2R1-EVO
Ab Junos OS Version 25.2R1 und Junos OS Evolved Version 25.2R1 können Sie mehrere gRPC-Server konfigurieren, die unterschiedliche Gruppen von Services auf eindeutigen Ports hosten.