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 クライアントとサーバー間の単純な接続を示しています。
![gRPC Server and Client Interaction](/documentation/us/en/software/junos/grpc-network-services/images/jn-000278.png)
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 アドレス フィールドが定義されている場合、認証時に [共通名] フィールドは無視されます。
要件 | サーバーのみの認証 | 相互認証 |
---|---|---|
証明 書 | サーバーには 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 サーバーの証明書を取得するには、次のようにします。
相互認証の場合は、gRPC クライアントの情報を使用して前の手順を繰り返し、クライアントのキーと証明書を生成します。クライアント証明書には、SAN IP 拡張フィールドは必要ありません。
gRPC サーバーのローカル証明書を Junos PKI に読み込みます。
gRPC サーバーを実行しているネットワーク デバイスには、gRPC クライアントに対してデバイスを識別する X.509 証明書が必要です。JunosデバイスでgRPCベースのサービスを実行するには、Junos PKIにローカルネットワークデバイスの公開キー証明書とキーを読み込む必要があります。証明書を読み込んで初期構成を実行すると、gRPC クライアントは任意のマイクロサービスを使用して証明書を更新できます。たとえば、gRPC クライアントは gNOI CertificateManagement
サービスを使用して、新しい証明書をインストールしたり、既存の証明書を置き換えたりできます。
ローカル デバイスの証明書とキーを PKI に読み込むには:
gRPC サービスを有効にする
gRPC ベースのサービスは、SSL(セキュア ソケット レイヤー)テクノロジに基づく API 接続設定を使用します。SSL ベースの接続の場合は、gRPC サーバーを識別するローカル証明書を指定する必要があります。
gRPC サービスを有効にしてローカル証明書を指定すると、ネットワーク デバイスはサーバーのみの認証を使用します。その後、「 gRPC サービスの相互 (双方向) 認証を構成する」で説明されている手順を実行して、必要に応じて相互認証を構成できます。
gRPC サービス用にネットワーク デバイスを構成し、サーバー認証に使用するローカル証明書を指定するには:
サーバーのみの認証ではなく相互認証を構成するには、「 gRPC サービスの相互 (双方向) 認証を構成する」の手順も実行する必要があります。
gRPC サービスの相互 (双方向) 認証を構成する
SSL 証明書を使用して、ネットワーク デバイスを gRPC サーバーとして認証し、ネットワーク管理システムを gRPC クライアントとして認証する gRPC セッションの相互(双方向)認証を構成できます。Junos デバイスは、外部クライアントから提供された認証情報を使用して、クライアントの認証と接続の承認を行います。
Junos デバイスでの相互認証は、次のいずれかのオプションを使用して構成できます。
-
階層レベルで相互認証設定
[edit system services extension-service request-response grpc ssl mutual-authentication]
を構成します。 -
最初にサーバーのみの認証を設定してから、gNOI
CertificateManagement
サービスを使用して必要な CA 証明書をデバイスに読み込みます。
デバイス構成で相互認証を直接構成する場合、デバイス構成は gNOI サービスを使用して行われた構成よりも優先されます。
始める前に:
-
Junos PKIにgRPCサーバーのローカル証明書を読み込むの説明に従って、gRPCサーバーとして機能するネットワークデバイスの証明書とキーをデバイスのPKIに読み込みます。
-
gRPC サービスを有効にし、「 gRPC サービスを有効にする」の説明に従ってローカル サーバー認証を構成します。
以下のセクションでは、相互認証を構成するさまざまな方法について説明します。環境に最適な方法を使用できます。
機器構成での相互認証の設定
ネットワーク デバイスの構成で gRPC クライアントの認証を直接構成するには:
-
クライアントの証明書を検証するために使用されるルート CA 証明書を、gRPC サーバーとして機能するローカル デバイスにダウンロードします。
-
階層で
[edit security pki]
、クライアント証明書のルート 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
。証明書を読み込んだ後、構成モードに入り、相互認証の構成を続行します。
-
相互認証を有効にし、クライアント証明書の要件を指定します。
[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
、テスト環境でのみ使用することをお勧めします。 -
クライアント証明書の検証に使用する認証局プロファイルを指定します。
認証局プロファイルは、ステップ 2 で構成されました。
[edit system services extension-service request-response grpc ssl] user@host# set mutual-authentication certificate-authority certificate-authority
例えば、以下の名前
gnoi-client
の認証局プロファイルを指定するには、[edit system services extension-service request-response grpc ssl] user@host# set mutual-authentication certificate-authority gnoi-client
-
設定をコミットします。
[edit] user@host# commit and-quit
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 証明書バンドルを読み込む場合、デバイスは暗黙的に相互認証を使用し、デバイスで明示的に設定されていなくても、次の構成を想定します。[edit system services extension-service request-response grpc ssl] mutual-authentication { certificate-authority gnoi-ca-bundle; client-certificate-request require-certificate-and-verify; }
-
CertificateManagagment
サービスが新しい CA 証明書バンドルを読み込む要求を送信すると、サーバーはデバイスから以前の CA バンドルの証明書をクリアし、新しい証明書を読み込みます。 -
サービスを使用して
CertificateManagagment
CA 証明書バンドルをロードし、ステートメント階層も設定[edit system services extension-service request-response grpc ssl mutual-authentication]
する場合は、設定されたステートメントが優先されます。
gRPC サービスのユーザー アカウントを構成する
チャネル資格情報は gRPC チャネルにアタッチされ、クライアント アプリケーションがサービスにアクセスできるようにします。呼び出し資格情報は特定の RPC 要求に添付され、クライアント アプリケーションを使用しているユーザーに関する情報を提供します。各 RPC 要求で通話資格情報を提供する必要があり、これにはネットワーク デバイスのユーザー アカウントが必要です。ユーザーは、ネットワークデバイス上でローカルに定義されたユーザーアカウントを持っているか、TACACS+ サーバーによって認証される必要があります。これにより、デバイスはローカルに定義されたユーザーテンプレートアカウントにユーザーをマッピングします。
ユーザーアカウントを作成するには
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
ここで package
、 、 service
および rpc
は、そのサービスの proto 定義ファイルのそれぞれのステートメントで定義されている名前です。例えば:
/gnmi.gNMI/Get /gnoi.certificate.CertificateManagement/Rotate /gnoi.system.System/Reboot /gnoi.system.System/RebootStatus /gribi.gRIBI/.*
1 つ以上の式を持つ複数の allow-grpc-rpc-regexps
and deny-grpc-rpc-regexps
ステートメントを設定できます。各式を引用符(" ")で囲みます。複数の式を角括弧 [ ] で囲み、式はスペースで区切ります。
allow-grpc-rpc-regexps ["regex1" "regex2" ... ] allow-grpc-rpc-regexps "regex3"
gRPC RPC の認証を定義するログイン クラスを作成するには: