Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

gRPC サービスを構成する

gRPC サーバーを設定して、gRPC ネットワーク操作インターフェイス(gNOI)サービス、gRPC ネットワーク管理インターフェイス(gNMI)サービス、gRPC ルーティング情報ベースインターフェイス(gRIBI)サービスなどのサービスを、クライアントがネットワーク デバイス上で gRPC サービスを使用できるようにします。

このトピックでは、認証のオプションや各オプションの設定方法など、Junos デバイスで gRPC サービスを設定する方法について説明します。サーバーとクライアントが gRPC セッションを確立する前に、次のセクションで説明する要件を満たす必要があります。

gRPC ベースのサービスの認証と許可について理解する

gNOI、gNMI、および gRIBI インターフェイスは、トランスポートに gRPC リモート プロシージャ コール フレームワークを使用します。gRPC サーバーはネットワーク デバイス上で実行され、指定されたポートで接続要求をリッスンします。gRPC クライアント アプリケーションは、リモート ネットワーク管理システム (NMS) で実行され、指定されたホストとポートでサーバーとの gRPC チャネルを確立します。クライアントは、SSL で暗号化された gRPC セッションを介して RPC を実行し、ネットワークサービス操作を実行します。 図 1 は、gRPC クライアントとサーバー間の単純な接続を示しています。

図 1: gRPC サーバーとクライアントの対話 gRPC Server and Client Interaction

gRPC チャネルは、チャネル資格情報を使用してサーバーとクライアント間の認証を処理します。標準チャネル資格情報では、サーバーとクライアントの認証に X.509 デジタル証明書を使用します。デジタル証明書は、 証明機関 または 証明機関 (CA) と呼ばれる信頼できる第三者を通じてユーザーを認証する方法を提供します。CA は、証明書所有者の ID を検証し、証明書が偽造または変更されていないことを証明するために証明書に「署名」します。X.509 標準では、証明書の形式が定義されています。デジタル証明書を使用すると、証明書の検証を通じて 2 つのエンドポイント間のセキュアな接続を確立できます。gRPC チャネルを確立するには、認証を必要とする各エンドポイント (デバイスまたはアプリケーション) が交換で X.509 証明書を提供する必要があります。

Junos デバイスは、サーバーのみの認証と SSL ベースの gRPC セッションの相互認証の両方をサポートします。サーバーのみの認証が構成されている場合、サーバーはチャネルの確立時に公開鍵証明書を提供します。クライアントは、サーバーのルート CA 証明書を使用してサーバーを認証します。相互認証が構成されている場合、クライアントはサーバーに接続するときに証明書も提供し、サーバーが証明書を検証します。証明書の検証が成功すると、クライアントは呼び出しを発信できます。相互認証を構成し、CA 署名付き証明書を使用してセキュリティを強化することをお勧めしますが、自己署名証明書も受け入れられます。

公開鍵基盤(PKI)は、公開暗号鍵の配布と識別をサポートし、ユーザーがインターネットなどのネットワーク上で安全にデータを交換することと、相手方の身元を確認することの両方を可能にします。gRPC ベースのサービスの場合、Junos PKI には、gRPC サーバーとして機能するローカル デバイスの証明書が含まれている必要があります。相互認証を使用する場合、Junos PKI には、デバイスに接続する gRPC クライアントの証明書を検証するために必要なルート CA 証明も含まれている必要があります。

表 1 は、gRPC クライアントがデバイスに接続して gRPC ベースのサービスを実行する場合の、サーバーのみの認証と相互認証の一般的な要件の概要を示しています。gRPC サーバーの証明書は、サーバーのホスト名を [Common Name (CN)] フィールドで定義するか、サーバーの IP アドレスを [Subject Alternative Name (subjectAltName or SAN) IP address] フィールドで定義する必要があります。クライアント・アプリケーションは、同じ値を使用してサーバーへの接続を確立する必要があります。証明書で SubjectAltName IP アドレス フィールドが定義されている場合、認証時に [共通名] フィールドは無視されます。

表 1: gRPC セッションのサーバーのみの認証と相互認証の要件
要件 サーバーのみの認証 相互認証
証明 書

サーバーには、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+サーバーによって認証される必要があります。その後、ユーザーはデバイス上でローカルに定義されたユーザーテンプレートアカウントにユーザーをマッピングします。呼び出し資格情報 (ユーザー名とパスワード) は、RPC の metadata 引数に指定できます。認証に成功すると、Junos デバイスは指定されたユーザーのアカウント権限を使用して RPC リクエストを実行します。

手記：

Junos デバイスで実行されるすべての RPC に呼び出し資格情報を渡す代わりに、Juniper 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 証明書の取得

SSL で暗号化された gRPC セッションは、X.509 公開キー証明書を使用して gRPC サーバーとクライアントを認証します。サーバーのみの認証の場合、gRPC サーバーには証明書が必要です。相互認証の場合は、gRPC サーバーとクライアントの両方に証明書が必要です。証明書の要件は次のとおりです。

  • 証明書は、認証局(CA)による署名または自己署名が可能です。

  • 証明書は PEM でエンコードされている必要があります。

  • gRPC サーバーの証明書は、共通名 (CN) フィールドで gRPC サーバーのホスト名を定義するか、SubjectAltName (SAN) IP アドレス フィールドで gRPC サーバーの IP アドレスを定義する必要があります。gRPC クライアントは、同じ値を使用してサーバーへの接続を確立する必要があります。証明書で SubjectAltName IP アドレスが定義されている場合、認証時に [共通名] フィールドは無視されます。

OpenSSL を使用して gRPC サーバーの証明書を取得するには:

  1. 秘密鍵を生成し、鍵の長さをビット単位で指定します。
  2. gRPC クライアントが gRPC サーバーの IP アドレスに接続する場合は、openssl.cnf または同等の構成ファイルを更新して、gRPC サーバーの IP アドレスで subjectAltName=IP 拡張機能を定義します。
  3. エンティティの公開キーと ID に関する情報を含む証明書署名要求 (CSR) を生成します。

    または、次のように 1 つのコマンドで CSR 情報を提供することもできます。

  4. 次のいずれかの方法で証明書を生成します。

    • CSR を認証局に送信して X.509 証明書を要求し、追加の拡張子を含む構成ファイルを提供します。

    • CA で CSR に署名して証明書を生成し、構成ファイルと拡張機能を参照する必要がある場合は -extfile オプションを含めます。

    • サーバーキーを使用してCSRに署名し、自己署名証明書を生成し、構成ファイルと拡張機能を参照する必要がある場合は -extfile オプションを含めます。

  5. 証明書の共通名 (CN) フィールドと拡張子 (指定されている場合) が正しいことを確認します。

相互認証の場合は、gRPC クライアントの情報を使用して前の手順を繰り返し、クライアントのキーと証明書を生成します。クライアント証明書には、SAN IP 拡張フィールドは必要ありません。

Junos PKIでgRPCサーバーのローカル証明書を読み込む

gRPC サーバーを実行するネットワーク デバイスには、gRPC クライアントに対してデバイスを識別する X.509 証明書が必要です。Junos デバイスで gRPC ベースのサービスを実行するには、Junos PKI でローカル ネットワーク デバイスの公開鍵証明書と鍵を読み込む必要があります。証明書を読み込んで初期構成を実行すると、gRPC クライアントは任意のマイクロサービスを使用して証明書を更新できます。例えば、gRPC クライアントは gNOI CertificateManagement サービスを使用して、新しい証明書をインストールしたり、既存の証明書を置き換えたりすることができます。

PKIにローカルデバイスの証明書とキーを読み込むには、次の手順に従います。

  1. gRPC サーバーとして機能しているデバイスの証明書とキーをそのデバイスにダウンロードします。
  2. 動作モードで、識別子を定義し、ローカルデバイスの証明書とキーをPKIに読み込みます。
  3. (オプション)証明書が PKI データベースに存在することを確認します。

gRPC サービスを有効にする

gRPC ベースのサービスでは、SSL(Secure Sockets Layer)テクノロジに基づく API 接続設定が使用されます。SSL ベースの接続の場合は、gRPC サーバーを識別するローカル証明書を指定する必要があります。

gRPC サービスを有効にし、ローカル証明書を指定すると、ネットワーク デバイスはサーバーのみの認証を使用します。その後、「 gRPC サービスの相互(双方向)認証の設定」で説明されている手順を完了することで、必要に応じて相互認証を設定できます。

ネットワーク デバイスを gRPC サービス用に構成し、サーバー認証に使用するローカル証明書を指定するには:

  1. gRPC サービスの SSL ベースの API 接続設定に移動します。
  2. gRPC サービスに使用するポートを構成します。

    例えば：

  3. ローカル証明書を指定します。

    request security pki local-certificate load運用モード コマンドで Junos PKI に読み込んだローカル証明書の識別子を入力します。

    次に、ローカル証明書 gnoi-serverを設定する例を示します。

  4. 証明書にPKIデータベースを使用するようにデバイスを設定します。
  5. デバイスが gRPC セッションを終了せずに証明書をリロードできるようにします。
  6. (オプション)着信接続をリッスンする IP アドレスを指定します。

    例えば：

    手記：

    IP アドレスを指定しない場合は、デフォルトのアドレスである :: を使用して着信接続をリッスンします。
  7. (オプション) 拡張サービスのトレースを構成して、発生する可能性のある問題をデバッグします。
    手記：

    拡張サービスの Junos OS Evolved トレース ファイルを表示するには、 show trace application jsd および show trace application jsd live 動作モード コマンドを使用します。
  8. 設定をコミットします。

サーバーのみの認証ではなく相互認証を構成するには、「 gRPC サービスの相互 (双方向) 認証を構成する」の手順も完了する必要があります。

gRPC サービスの相互(双方向)認証を設定する

gRPC セッションでは、SSL 証明書を使用してネットワーク デバイスを gRPC サーバーとして、ネットワーク管理システムを gRPC クライアントとして認証する相互(双方向)認証を構成できます。Junos デバイスは、外部クライアントから提供された認証情報を使用して、クライアントを認証し、接続を承認します。

以下のオプションのいずれかを使用して、Junosデバイスで相互認証を設定できます。

  • 相互認証の設定は、 [edit system services extension-service request-response grpc ssl mutual-authentication] 階層レベルの直下で行います。

  • 最初にサーバーのみの認証を設定してから、gNOI CertificateManagement サービスを使用してデバイスに必要なCA 証明をロードします。

デバイス設定で相互認証を直接設定すると、gNOI サービスを使用して行われた設定よりもデバイス設定が優先されます。

開始する前に、以下を実行します。

次のセクションでは、相互認証を構成するさまざまな方法について説明します。環境に最適な方法を使用できます。

デバイス構成で相互認証を設定する

gRPC クライアントの認証をネットワーク デバイス構成で直接構成するには:

  1. クライアントの証明書を検証するために使用されるルート CA 証明書を、gRPC サーバーとして機能するローカル デバイスにダウンロードします。

  2. クライアント証明書のルートCAの認証局プロファイルを [edit security pki] 階層で構成します。

    例えば：

  3. 設定をコミットします。

  4. 動作モードで、クライアントの証明書の検証に使用するルートCA証明書をJunos PKIに読み込みます。前の手順で設定した ca-profile 識別子を指定します。

    例えば：

    先端：

    CA 証明書バンドルをロードするには、 request security pki ca-certificate ca-profile-group load ca-group-name ca-group-name filename bundle-path コマンドを発行します。

    証明書を読み込んだら、構成モードに入り、相互認証の構成を続行します。

  5. 相互認証を有効にし、クライアント証明書の要件を指定します。

    たとえば、証明書とその検証を必要とする最も強力な認証を指定するには、 require-certificate-and-verify を使用します。

    手記：

    デフォルトは no-certificateです。その他のオプションは、 request-certificate、 request-certificate-and-verify、 require-certificate、 require-certificate-and-verifyです。

    no-certificate オプションは、テスト環境でのみ使用することをお勧めします。

  6. クライアント証明書の検証に使用する認証局プロファイルを指定します。

    認証局のプロファイルは、ステップ 2 で設定しました。

    例えば、 gnoi-clientという名前の認証局プロファイルを指定するには、次のようにします。

  7. 設定をコミットします。

gNOI CertificateManagement サービスを使用した相互認証の設定

デバイス構成で直接設定を行う代わりに、gNOI CertificateManagementサービスを使用して gRPC クライアントと gRPC サーバー間の相互認証を設定できます。最初にサーバーのみの認証を設定してから、gNOI CertificateManagement サービス 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 証明書バンドルをロードし、[edit system services extension-service request-response grpc ssl mutual-authentication] ステートメント階層も設定した場合、設定されたステートメントが優先されます。

gRPC サービスのユーザー アカウントを構成する

チャネル資格情報は gRPC チャネルにアタッチされ、クライアント アプリケーションがサービスにアクセスできるようにします。呼び出し資格情報は、特定の RPC 要求に添付され、クライアント アプリケーションを使用しているユーザーに関する情報を提供します。各 RPC 要求で呼び出し資格情報を提供する必要があり、これにはネットワーク デバイスのユーザー アカウントが必要です。ユーザは、ネットワークデバイス上でローカルに定義されたユーザーアカウントを持っているか、TACACS+サーバーによって認証される必要があります。その後、デバイスはデバイス上でローカルに定義されたユーザーテンプレートアカウントにユーザーをマッピングします。

ユーザーアカウントを作成するには

  1. userステートメントを一意のユーザー名で設定し、classステートメントを含めて、ユーザーが実行するすべてのアクションに必要な権限を持つログインクラスを指定します。例えば：
  2. ローカル・ユーザー・アカウントの場合は、ユーザーのパスワードを構成します。

    ローカル ユーザー テンプレート アカウントのパスワードは、リモート認証サーバーを介して認証されるため、省略できます。

  3. (オプション)full-name ステートメントを設定して、ユーザー名を指定します。
  4. 設定をコミットして、デバイスのユーザーアカウントを有効化します。
  5. gRPC クライアントが gRPC セッションで RPC を実行する各ネットワーク デバイスで、上記の手順を繰り返します。

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 は、そのサービスのプロト定義ファイルのそれぞれのステートメントで定義されている名前です。例えば：

1つ以上の式で複数の allow-grpc-rpc-regexps および deny-grpc-rpc-regexps ステートメントを設定できます。各式を引用符(" ")で囲みます。複数の式を角括弧[ ]で囲み、スペースで区切ります。

gRPC RPCの認証を定義するログインクラスを作成するには、以下を行います。

  1. ログインクラス名と権限を設定します。

    例えば：

  2. クラス内で、クラスが許可するRPCの正規表現を設定します。

    たとえば、次のステートメントは、gNMI Get() RPC とすべての gNOI System サービス RPC を許可します。

  3. クラスが拒否するRPCの正規表現を設定します。

    例えば、以下のステートメントは、gNMI Set() RPC を拒否し、 gRIBI サービスと gNOI CertificateManagement サービスのすべての RPC も拒否します。

  4. ログインクラスを適切な gRPC ユーザーに割り当てます。

    たとえば、次の文は、 grpc-operator クラスを grpc-user ユーザに割り当てます。

ネットワーク デバイスで gRPC サービスを有効にした後、リモート ネットワーク管理システムを gRPC クライアントとして設定します。クライアントが gNOI 操作を実行できるようにするには、 gNOI サービスの設定で説明されているようにクライアントを設定します。