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 は、証明書所有者の身元を確認し、証明書が偽造または変更されていないことを証明するために証明書に「署名」します。X.509 標準では、証明書の形式が定義されています。デジタル証明書を使用すると、証明書の検証によって 2 つのエンドポイント間にセキュアな接続を確立できます。gRPC チャネルを確立するには、認証を必要とする各エンドポイント (デバイスまたはアプリケーション) が交換で X.509 証明書を提供する必要があります。

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

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

表 1 は、gRPC クライアントがデバイスに接続して gRPC ベースのサービスを実行する場合の、サーバーのみの認証と相互認証の一般的な要件の概要を示しています。gRPC サーバーの証明書では、[共通名 (CN)] フィールドでサーバーのホスト名を定義するか、[サブジェクトの別名 (subjectAltName または SAN) IP アドレス] フィールドでサーバーの IP アドレスを定義する必要があります。クライアント アプリケーションは、サーバーへの接続を確立するために同じ値を使用する必要があります。証明書で 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 Extension Toolkit jnx_authentication_service API を使用してgRPCセッションの開始時に一度デバイスにログインし、チャネルで実行される後続のすべてのRPCが認証されるようにすることができます。JETクライアントIDLライブラリは、 ジュニパーネットワークスのダウンロードサイトからダウンロードできます。

デフォルトでは、Junos デバイスは、認証された gRPC クライアントにすべての gRPC RPC の実行を許可します。オプションで、gRPC ユーザーのログイン クラスを構成して、特定の gRPC RPC を明示的に許可または拒否できます。RPCを指定するには、 および deny-grpc-rpc-regexps ステートメントを設定しallow-grpc-rpc-regexps、RPCに一致する正規表現を定義します。詳細については、「gRPC RPC 承認を構成する」を参照してください。

X.509 証明書を取得する

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

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

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

  • gRPC サーバーの証明書では、gRPC サーバーのホスト名を [共通名 (CN)] フィールドに定義するか、gRPC サーバーの IP アドレスを SubjectAltName (SAN) 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 拡張フィールドは必要ありません。

gRPC サーバーのローカル証明書を Junos PKI に読み込みます。

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

ローカル デバイスの証明書とキーを PKI に読み込むには:

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

gRPC サービスを有効にする

gRPC ベースのサービスは、SSL(セキュア ソケット レイヤー)テクノロジに基づく API 接続設定を使用します。SSL ベースの接続の場合は、gRPC サーバーを識別するローカル証明書を指定する必要があります。

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

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

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

    例えば：

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

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

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

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

    例えば：

    メモ：

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

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

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

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

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

Junos デバイスでの相互認証は、次のいずれかのオプションを使用して構成できます。

  • 階層レベルで相互認証設定 [edit system services extension-service request-response grpc ssl mutual-authentication] を構成します。

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

デバイス構成で相互認証を直接構成する場合、デバイス構成は gNOI サービスを使用して行われた構成よりも優先されます。

始める前に:

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

機器構成での相互認証の設定

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

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

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

    例えば：

  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-certificaterequire-certificate-and-verifyです。

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

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

    認証局プロファイルは、ステップ 2 で構成されました。

    例えば、以下の名前 gnoi-clientの認証局プロファイルを指定するには、

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

gNOI 証明書管理サービスを使用した相互認証の設定

gNOI CertificateManagagment サービスを使用すると、デバイス構成で直接設定を構成する代わりに、gRPC クライアントと gRPC サーバー間の相互認証を設定できます。最初にサーバーのみの認証を設定してから、gNOI CertificateManagement サービス RPC を使用してクライアント CA 証明書をロードします。gNOI サービスを使用した証明書のロードについては、 gNOI CertificateManagagment 証明書管理サービスを参照してください。

gRPC サーバーは、gNOI サービスに対して 1 つのグローバル CA 証明書バンドルのみをサポートします。gNOI CertificateManagagment サービスを使用して CA 証明書バンドルをロードする場合、デバイスは暗黙的に相互認証を使用します。ただし、次の点に注意する必要があります。

  • サービスは常にCertificateManagagment、予約された識別子gnoi-ca-bundleを使用して CA 証明書バンドルを読み込みますca-profile-group。

  • サービスを使用して CertificateManagagment CA 証明書バンドルを読み込む場合、デバイスは暗黙的に相互認証を使用し、デバイスで明示的に設定されていなくても、次の構成を想定します。

  • CertificateManagagmentサービスが新しい CA 証明書バンドルを読み込む要求を送信すると、サーバーはデバイスから以前の CA バンドルの証明書をクリアし、新しい証明書を読み込みます。

  • サービスを使用して CertificateManagagment 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を指定するには、 および deny-grpc-rpc-regexps ステートメントを設定しallow-grpc-rpc-regexps、RPCに一致する正規表現を定義します。許可リストと拒否リストに矛盾する式がある場合は、拒否リストが優先されます。RPC がどちらのリストにも一致しない場合、RPC は既定で許可されます。

Junosデバイスでは、gRPC RPCの指定に次の構文を使用します。

ここで package、 、 serviceおよび rpc は、そのサービスの proto 定義ファイルのそれぞれのステートメントで定義されている名前です。例えば：

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

gRPC RPC の認証を定義するログイン クラスを作成するには:

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

    例えば：

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

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

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

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

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

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

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