gRPCサービスを設定する
gRPC サーバーを設定して、クライアントがネットワーク デバイス上でgRPC サービス(gNOI)サービス、gRPC ネットワーク管理インターフェイス(gNMI)サービス、gRPC ルーティング情報ベースインターフェイス(gRIBI)サービスなどのサービスを使用できるようにします。
このトピックでは、認証のオプションと各オプションの設定方法を含め、Junosデバイス上でgRPCサービスを設定する方法について説明します。サーバーとクライアントがgRPCセッションを確立する前に、次のセクションで説明する要件を満たす必要があります。
gRPCベースのサービスの認証と許可について
gNMI、gNOI、gRIBIインターフェイスは、トランスポートにgRPCリモートプロシージャコールフレームワークを使用します。gRPCサーバーはネットワークデバイス上で動作し、指定されたポートで接続要求をリッスンします。gRPCクライアントアプリケーションは、リモートネットワーク管理システム(NMS)上で実行され、指定されたホストとポート上のサーバーとgRPCチャネルを確立します。クライアントは、SSL暗号化gRPCセッションを介してRPCを実行し、ネットワークサービス操作を実行します。 図 1 は、gRPC クライアントとサーバー間の単純な接続を示しています。
gRPCチャネルは、チャネル資格情報を使用して、サーバーとクライアント間の認証を処理します。標準チャネル資格情報では、サーバーとクライアントの認証にX.509デジタル証明書を使用します。デジタル証明書は、 認証機関 または 認証機関 (CA) と呼ばれる信頼できるサード パーティを介してユーザーを認証する方法認定を提供します。CA は証明書所有者の身元を確認し、証明書が偽造または改ざんされていないことを証明するために証明書に「署名」します。X.509標準は、証明書の形式を定義しています。デジタル証明書を使用して、証明書の検証を通じて 2 つのエンドポイント間の安全な接続を確立できます。gRPCチャネルを確立するには、認証を必要とする各エンドポイント(デバイスまたはアプリケーション)が交換でX.509証明書を提供する必要があります。
Junosデバイスは、サーバーのみの認証と、SSLおよびTLSベースのgRPCセッションの相互認証の両方をサポートします。サーバーのみの認証が設定されている場合、チャネルが確立されるとサーバーは公開キー証明書を提供します。クライアントは、サーバーのルート CA 証明書を使用してサーバーを認証します。相互認証が設定されている場合、クライアントはサーバーに接続するときにも証明書を提供し、サーバーは証明書を検証します。証明書の検証に成功すると、クライアントは呼び出しを発信できます。自己署名証明書も受け入れられますが、相互認証を設定し、CA署名証明書を使用することを推奨します。
公開鍵基盤(PKI)は、公開暗号化鍵の配布と識別をサポートします。これにより、ユーザーはインターネットなどのネットワーク上で安全にデータを交換したり、相手の身元を確認することができます。gRPC ベースのサービスの場合、Junos PKI には、gRPC サーバーとして機能するローカルデバイスの証明書が含まれている必要があります。相互認証を使用する場合、デバイスに接続するgRPCクライアントの証明書を検証するために必要なルートCA証明書もJunos PKIに含まれている必要があります。
表1は 、gRPCクライアントがgRPCベースのサービスを実行するためにデバイスに接続する際の、サーバーのみの認証と相互認証の一般的な要件を概説しています。gRPCサーバーの証明書は、共通名(CN)フィールドにサーバーのホスト名を定義するか、サブジェクトの代替名(subjectAltNameまたはSAN)IPアドレスフィールドにサーバーのIPアドレスを定義する必要があります。クライアントアプリケーションは、サーバーへの接続を確立するために同じ値を使用する必要があります。証明書でSubjectAltName IPアドレスフィールドが定義されている場合、認証中に共通名フィールドは無視されます。
| 要件 | サーバーのみの認証 | 相互認証 |
|---|---|---|
| 証明書 | サーバーには、X.509公開キー証明書が必要です。 クライアントがホスト名ではなくサーバーのIPアドレスに接続する場合、サーバーの証明書には、サーバーのIPアドレスを含むsubjectAltName(SAN)IPアドレス拡張フィールドを含める必要があります。 |
サーバーとクライアントには、それぞれ X.509 パブリック キー証明書が必要です。 クライアントがホスト名ではなくサーバーのIPアドレスに接続する場合、サーバーの証明書には、サーバーのIPアドレスを含むsubjectAltName(SAN)IPアドレス拡張フィールドを含める必要があります。 |
| Junos PKI | サーバーのローカル証明書は、Junos PKI に読み込む必要があります。 |
サーバーのローカル証明書と各クライアントのルート CA 証明書を Junos PKI に読み込む必要があります。 |
| チャネル資格情報 | gRPCチャネルが確立されると、クライアントはサーバーのルートCA証明書を渡す必要があります。 |
gRPCチャネルが確立されると、クライアントは証明書とキー、およびサーバーのルートCA証明書を渡す必要があります。 |
チャネル資格情報はgRPCチャネルにアタッチされ、クライアントアプリケーションがサービスにアクセスできるようにします。一方、呼び出し資格情報は、特定のサービス操作 (RPC 要求) に添付され、クライアント アプリケーションを使用しているユーザーに関する情報を提供します。呼び出し資格情報は、要求ごと、つまり RPC 呼び出しごとに送信されます。JunosデバイスでgRPCベースの操作を実行するには、リクエストで通話資格情報を提供する必要があります。ユーザーは、デバイス上でローカルに定義されたユーザーアカウントを持っているか、TACACS+サーバーによって認証されている必要があります。その後、TACACS+サーバーがデバイス上でローカルに定義されたユーザーテンプレートアカウントにユーザーをマッピングします。RPCの metadata 引数で通話資格情報(ユーザー名とパスワード)を指定できます。認証に成功すると、Junosデバイスは指定されたユーザーのアカウント権限を使用してRPCリクエストを実行します。
Junos デバイスで実行されるすべての RPC の呼び出し資格情報を渡す代わりに、ジュニパー Juniper Extension Toolkit jnx_authentication_service API を使用して、gRPC セッションの開始時に一度デバイスにログインし、チャネルで実行される後続のすべての RPC が認証されます。JETクライアントIDLライブラリは、 ジュニパーネットワークスのダウンロードサイトからダウンロードできます。
デフォルトでは、Junosデバイスは、認証されたgRPCクライアントにすべてのgRPC RPCの実行を承認します。オプションで、gRPCユーザーのログインクラスを設定して、特定のgRPC RPCを明示的に許可または拒否することができます。RPCを指定するには、 allow-grpc-rpc-regexps ステートメントと deny-grpc-rpc-regexps ステートメントを設定し、RPCに一致する正規表現を定義します。詳細については、「 gRPC RPC 認証の設定 」を参照してください。
X.509証明書を取得する
gRPCセッションは、X.509公開キー証明書を使用してgRPCサーバーとクライアントを認証します。サーバーのみの認証では、gRPCサーバーに証明書が必要です。相互認証のためには、gRPCサーバーとクライアントの両方に証明書が必要です。証明書の要件は以下の通りです。
-
証明書は、CA による署名または自己署名が可能です。
-
証明書はPEMでエンコードされている必要があります。
-
gRPCサーバーの証明書は、共通名(CN)フィールドにgRPCサーバーのホスト名を定義するか、SubjectAltName(SAN)IPアドレスフィールドにgRPCサーバーのIPアドレスを定義する必要があります。gRPC クライアントは、サーバーへの接続を確立するために同じ値を使用する必要があります。証明書で SubjectAltName IP アドレスが定義されている場合、認証中に [共通名] フィールドは無視されます。
OpenSSL を使用して gRPC サーバーの証明書を取得するには:
相互認証のために、gRPC クライアントの情報を使用して前の手順を繰り返し、クライアントの鍵と証明書を生成します。クライアント証明書には、SAN IP拡張子フィールドは必要ありません。
gRPCサーバーのローカル証明書をJunos PKIに読み込みます
gRPC サーバーを実行するネットワーク デバイスには、gRPC クライアントに対してデバイスを識別する X.509 証明書が必要です。JunosデバイスでgRPCベースのサービスを実行するには、ローカルネットワークデバイスの公開キー証明書とキーをJunos PKIにロードする必要があります。証明書を読み込んで初期設定を実行すると、gRPC クライアントは任意のマイクロサービスを使用して証明書を更新できます。例えば、gRPC クライアントは、gNOI CertificateManagement サービスを使用して、新しい証明書をインストールしたり、既存の証明書を置き換えたりできます。
ローカルデバイスの証明書とキーをPKIに読み込むには:
gRPCサービスを有効にする
gRPCベースのサービスは、SSL(Secure Socket Layer)またはTLS(トランスポート層 セキュリティ)テクノロジーに基づくAPI接続設定を使用します。これらの接続では、gRPCサーバーを識別するローカル証明書を指定する必要があります。
gRPCサービスを有効にし、ローカル証明書を指定すると、ネットワークデバイスはサーバーのみの認証を使用します。その後、 gRPCサービスの相互(双方向)認証を設定するで説明されている手順を完了することで、オプションで相互認証を設定することができます。
gRPCサービス用にネットワークデバイスを設定し、以下の階層レベルのいずれかでサーバー認証に使用するローカル証明書を指定できます。
-
[edit system services http servers]—このステートメント階層を使用して、固有のポートで異なるサービスセットをホストする1つ以上のgRPCサーバーを設定します。さらに、各サーバーは異なるリスニングアドレス、証明書、ルーティングインスタンスをサポートできます。 -
[edit system services extension-service request-response grpc ssl]—このステートメント階層は、同じリスニングアドレスとポートですべてのgRPCサービスをサポートする単一のgRPCサーバーのみが必要な場合に使用します。
gRPCサービス用にデバイスを設定するには、環境の要件を満たす階層レベルの指示に従ってください。
[edit system services http servers][edit system services extension-service request-response grpc ssl]
[edit system services http servers]
[edit system services http servers]階層レベルで1つ以上のgRPCサーバーを設定するには:
gRPCサーバーの階層レベルに移動し、サーバーの識別子を指定します。
[edit] user@host# edit system services http servers server name
次に例を示します。
[edit] user@host# edit system services http servers server grpc-server1
gRPCサービスに使用するポートを設定します。ポートは、gRPCサーバーごとに固有である必要があります。
[edit system services http servers server name] user@host# set port port-number
次に例を示します。
[edit system services http servers server grpc-server1] user@host# set port 32767
このサーバーでホストされるgRPCサービスを設定します。
[edit system services http servers server name] user@host# set grpc [service1 service2 ...]
この例では、サーバーがgNMIサービスとgNOIサービスをホストしています。
[edit system services http servers server grpc-server1] user@host# set grpc [gnmi gnoi]
クライアントに対してサーバーを識別するローカル証明書を指定します。
以前に
request security pki local-certificate load動作モードコマンドを使用してJunos PKIにロードしたローカル証明書の識別子を入力します。[edit system services http servers server name] user@host# set tls local-certificate certificate-id
以下の例では、ローカル証明書
gnoi-serverを設定します。[edit system services http servers server grpc-server1] user@host# set tls local-certificate gnoi-server
(オプション)サーバーが着信接続をリッスンする IPv4 または IPv6 アドレスを指定します。
[edit system services http servers server name] user@host# set listen-address address
次に例を示します。
[edit system services http servers server grpc-server1] user@host# set ip-address 192.168.2.1
注:IPアドレスを指定しない場合、デフォルトのアドレス::が使用されて受信接続をリッスンします。
(オプション)デフォルトのルーティングインスタンスと異なる場合は、このgRPCサーバーに使用するルーティングインスタンスを設定します。
[edit system services http servers server name] user@host# set routing-instance routing-instance
次の例では、mgmt-junosルーティングインスタンスを使用しています。
[edit system services http servers server grpc-server1] user@host# set routing-instance mgmt-junos
(オプション)このgRPCサーバーがサポートする接続の最大数を設定します。
[edit system services http servers server name] user@host# set max-connections connections
次の例では、最大10個の接続を設定します。デフォルトは5です。
[edit system services http servers server grpc-server1] user@host# set max-connections 10
設定をコミットします。
user@host# commit
サーバーのみの認証ではなく、相互認証を設定するには、 gRPCサービスの相互(双方向)認証の設定の手順も完了する必要があります。
[edit system services extension-service request-response grpc ssl]
[edit system services extension-service request-response grpc ssl]階層レベルで単一のgRPCサーバーを設定するには:
gRPCサービスのSSLベースAPI接続設定に移動します。
[edit] user@host# edit system services extension-service request-response grpc ssl
gRPCサービスに使用するポートを設定します。
[edit system services extension-service request-response grpc ssl] user@host# set port port-number
次に例を示します。
[edit system services extension-service request-response grpc ssl] user@host# set port 32767
クライアントに対してサーバーを識別するローカル証明書を指定します。
以前に
request security pki local-certificate load動作モードコマンドでJunos PKIにロードしたローカル証明書の識別子を入力します。[edit system services extension-service request-response grpc ssl] user@host# set local-certificate certificate-id
以下の例では、ローカル証明書
gnoi-serverを設定します。[edit system services extension-service request-response grpc ssl] user@host# set local-certificate gnoi-server
証明書にPKIデータベースを使用するようにデバイスを構成します。
[edit system services extension-service request-response grpc ssl] user@host# set use-pki
デバイスがgRPCセッションを終了せずに証明書をリロードできるようにします。
[edit system services extension-service request-response grpc ssl] user@host# set hot-reloading
(オプション)着信接続をリッスンするIPアドレスを指定します。
[edit system services extension-service request-response grpc ssl] user@host# set ip-address address
次に例を示します。
[edit system services extension-service request-response grpc ssl] user@host# set ip-address 192.168.2.1
注:IPアドレスを指定しない場合、デフォルトのアドレス::が使用されて受信接続をリッスンします。
(オプション)拡張サービスのトレースを設定して、発生する可能性のある問題をデバッグします。
[edit] user@host# top user@host# set system services extension-service traceoptions file jsd user@host# set system services extension-service traceoptions flag all
注:拡張サービスの Junos OS Evolved トレース ファイルを表示するには、
show trace application jsdおよびshow trace application jsd live動作モード コマンドを使用します。設定をコミットします。
user@host# commit
サーバーのみの認証ではなく、相互認証を設定するには、 gRPCサービスの相互(双方向)認証の設定の手順も完了する必要があります。
gRPCサービスの相互(双方向)認証を設定する
gRPCセッションの相互(双方向)認証を設定することで、証明書を使用してネットワークデバイスをgRPCサーバーとして、NMSをgRPCクライアントとして認証することができます。Junosデバイスは、外部クライアントから提供された認証情報を使用して、クライアントを認証し、接続を承認します。
以下のオプションのいずれかを使用して、Junosデバイス上で相互認証を構成できます。
-
相互認証設定を構成で直接構成します。
-
最初にサーバー専用認証を設定してから、gNOI
CertificateManagementサービスを使用して必要なCA証明書をデバイスに読み込みます。
デバイス設定で相互認証を直接設定する場合、デバイス設定がgNOIサービスを使用して行われた設定よりも優先されます。
始める前に:
-
gRPCサーバーとして機能するネットワークデバイスの証明書とキーを、 Junos PKIにgRPCサーバーのローカル証明書を読み込むの説明に従って、デバイスのPKIにロードします。
-
gRPCサービスを有効にし、 gRPCサービスを有効にするの説明に従ってローカルサーバー認証を設定します。
以下のセクションでは、相互認証を設定するさまざまな方法について説明します。ご使用の環境に最適な方法を使用できます。
デバイス構成で相互認証を構成する
ネットワークデバイス設定で直接gRPCクライアントの認証を設定するには:
クライアントの証明書の検証に使用するルート CA 証明書を、gRPC サーバーとして機能するローカル デバイスにダウンロードします。
[edit security pki]階層でクライアント証明書のルートCAのCAプロファイルを設定します。[edit security pki] user@host# set ca-profile ca-profile-name ca-identity ca-identifier
次に例を示します。
[edit security pki] user@host# set ca-profile gnoi-client ca-identity clientRootCA
設定をコミットします。
[edit] user@host# commit and-quit
動作モードで、クライアントの証明書の検証に使用するルート CA 証明書を Junos PKI にロードします。前の手順で設定した
ca-profile識別子を指定します。user@host> request security pki ca-certificate load ca-profile ca-profile filename cert-path
次に例を示します。
user@host> request security pki ca-certificate load ca-profile gnoi-client filename /var/tmp/clientRootCA.crt Fingerprint: 00:2a:30:e9:59:94:db:f1:a1:5c:d1:c9:d4:5f:db:8f:f1:f0:8d:c4 (sha1) 02:3b:a0:b8:95:0c:a2:fa:15:18:57:3d:a3:10:e9:ac (md5) 69:97:90:39:de:75:a0:1d:94:1e:06:a8:be:8c:66:e5:41:95:fd:dc:14:8a:e7:3a:e0:42:9e:f9:f7:dd:c8:c2 (sha256) Do you want to load this CA certificate ? [yes,no] (no) yes CA certificate for profile gnoi-client loaded successfully
ヒント:CA証明書バンドルを読み込むには、
request security pki ca-certificate ca-profile-group load ca-group-name ca-group-name filename bundle-pathコマンドを発行します。証明書を読み込んだ後、設定モードに入り、相互認証の設定を続行します。サーバーを設定したのと同じ階層レベルで相互認証を設定する必要があります。階層レベルに合わせて、セクションで概説されている手順を実行します。
[システムサービスのHTTPサーバーを編集]
[edit system services http servers]階層レベルで設定されたサーバーの相互認証を設定するには:
サーバー設定の下にある
tlsステートメントに移動します。[edit] user@host# edit system services http servers server name tls
次に例を示します。
[edit] user@host# edit system services http servers server grpc-server1 tls
相互認証を有効にし、クライアント証明書の要件を指定します。
[edit system services http servers server name tls] user@host# set mutual-authentication authentication-type requirement
例えば、証明書とその検証を必要とする最強の認証を指定するには、デフォルトでもある
request-and-require-cert-and-verifyを使用します。[edit system services http servers server grpc-server1 tls] user@host# set mutual-authentication authentication-type request-and-require-cert-and-verify
クライアント証明書の検証に使用するCAプロファイルを指定します。
CAプロファイルは、CAプロファイル設定のステップ 2 でCAプロファイル設定されました。
[edit system services http servers server name tls] user@host# set mutual-authentication certificate-authority certificate-authority
例えば、
gnoi-clientという名前のCAプロファイルを指定するには:[edit system services http servers server grpc-server1 tls] user@host# set mutual-authentication certificate-authority gnoi-client
設定をコミットします。
[edit system services http servers server name tls] user@host# commit and-quit
[システムサービス拡張サービスリクエスト応答gRPC SSLの編集]
[edit system services extension-service request-response grpc ssl]階層レベルで設定されたサーバーの相互認証を設定するには:
相互認証を有効にし、クライアント証明書の要件を指定します。
[edit system services extension-service request-response grpc ssl] user@host# set mutual-authentication client-certificate-request requirement
たとえば、証明書とその検証を必要とする最も強力な認証を指定するには、
require-certificate-and-verifyを使用します。[edit system services extension-service request-response grpc ssl] user@host# set mutual-authentication client-certificate-request require-certificate-and-verify
注:デフォルトは
no-certificateです。その他のオプションは、request-certificate、request-certificate-and-verify、require-certificate、require-certificate-and-verifyです。no-certificateオプションは、テスト環境でのみ使用することをお勧めします。クライアント証明書の検証に使用するCAプロファイルを指定します。
CAプロファイルは、CAプロファイル設定のステップ 2 でCAプロファイル設定されました。
[edit system services extension-service request-response grpc ssl] user@host# set mutual-authentication certificate-authority certificate-authority
例えば、
gnoi-clientという名前のCAプロファイルを指定するには、次のようにします。[edit system services extension-service request-response grpc ssl] user@host# set mutual-authentication certificate-authority gnoi-client
設定をコミットします。
[edit system services extension-service request-response grpc ssl] user@host# commit and-quit
gNOI CertificateManagement サービスを使用して相互認証を設定する
gNOI CertificateManagementサービスを使用して、デバイス構成で直接設定を構成する代わりに、gRPCクライアントとgRPCサーバー間の相互認証を設定できます。最初にサーバーのみの認証を設定してから、gNOICertificateManagementサービスRPCを使用してクライアントCA証明書を読み込みます。gNOI CertificateManagementサービスを使用した証明書の読み込みについては、「gNOI 証明書管理サービス」を参照してください。
gRPCサーバーは、gNOIサービス用に1つのグローバルCA証明書バンドルのみをサポートします。gNOI CertificateManagement サービスを使用してCA証明書バンドルを読み込むと、デバイスは暗黙的に相互認証を使用します。ただし、以下の点に注意する必要があります。
-
CertificateManagementサービスは、常にca-profile-group予約済み識別子gnoi-ca-bundleを使用してCA証明書バンドルを読み込みます。 -
CertificateManagementサービスを使用してCA証明書バンドルを読み込む場合、デバイスは暗黙的に相互認証を使用します。 -
CertificateManagementサービスが新しいCA証明書バンドルを読み込むリクエストを送信した場合、サーバーはデバイスから以前のCAバンドルの証明書をクリアし、新しい証明書を読み込みます。 -
CertificateManagementサービスを使用してCA証明書バンドルを読み込み、デバイス設定で相互認証を明示的に設定する場合は、設定されたステートメントが優先されます。
gRPCサービス用にユーザーアカウントを設定する
チャネル資格情報はgRPCチャネルにアタッチされ、クライアントアプリケーションがサービスにアクセスできるようにします。呼び出し資格情報は特定の RPC 要求に添付され、クライアント アプリケーションを使用しているユーザーに関する情報を提供します。各 RPC 要求で通話資格情報を指定する必要があり、これにはネットワーク デバイスのユーザー アカウントが必要です。ユーザーは、ネットワークデバイス上でローカルに定義されたユーザーアカウントを持っているか、TACACS+サーバーによって認証される必要があります。その後、TACACS+サーバーは、デバイス上でローカルに定義されたユーザーテンプレートアカウントにユーザーをマッピングします。
ユーザーアカウントを作成するには:
gRPC RPC認証を設定する
デフォルトでは、Junosデバイスは、認証されたgRPCクライアントにすべてのgRPC RPCの実行を承認します。Junosログインクラスを設定して、gRPC RPCを明示的に許可または拒否できます。RPCを指定するには、 allow-grpc-rpc-regexps ステートメントと deny-grpc-rpc-regexps ステートメントを設定し、RPCに一致する正規表現を定義します。許可リストと拒否リストに矛盾する式がある場合は、拒否リストが優先されます。RPC がどちらのリストにも一致しない場合、デフォルトで RPC が許可されます。
Junosデバイスは、gRPC RPCを指定するために以下の構文を使用します。
/package.service/rpc
ここで、 package、 service、および rpc は、そのサービスのプロト定義ファイル内のそれぞれのステートメントで定義された名前です。次に例を示します。
/gnmi.gNMI/Get /gnoi.certificate.CertificateManagement/Rotate /gnoi.system.System/Reboot /gnoi.system.System/RebootStatus /gribi.gRIBI/.*
1つ以上の式で複数の allow-grpc-rpc-regexps および deny-grpc-rpc-regexps ステートメントを設定できます。各式を引用符(" ")で囲みます。複数の式を角括弧[ ]で囲み、式をスペースで区切ります。
allow-grpc-rpc-regexps ["regex1" "regex2" ... ] allow-grpc-rpc-regexps "regex3"
gRPC RPC の認証を定義するログインクラスを作成するには:
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。