Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의 내용
 

gRPC 서비스 구성

클라이언트가 네트워크 디바이스에서 gRPC gNOI(네트워크 운영 인터페이스) 서비스, gRPC 네트워크 관리 인터페이스(gNMI) 서비스 및 gRPC 라우팅 정보 기반 인터페이스(gRIBI) 서비스를 사용할 수 있도록 gRPC 서버를 구성합니다.

이 주제에서는 인증 옵션 및 각 옵션 구성 방법을 포함하여 Junos 디바이스에서 gRPC 서비스를 구성하는 방법에 대해 설명합니다. 서버와 클라이언트가 gRPC 세션을 설정하려면 먼저 다음 섹션에서 설명하는 요구 사항을 충족해야 합니다.

gRPC 기반 서비스에 대한 인증 및 권한 부여 이해

gNMI, gNOI 및 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 표준은 인증서의 형식을 정의합니다. 디지털 인증서는 인증서 유효성 검사를 통해 두 엔드포인트 간에 보안 연결을 설정하는 데 사용할 수 있습니다. gRPC 채널을 설정하려면 인증이 필요한 각 엔드포인트(디바이스 또는 애플리케이션)가 교환에서 X.509 인증서를 제공해야 합니다.

Junos 디바이스는 서버 전용 인증과 SSL 및 TLS 기반 gRPC 세션에 대한 상호 인증을 모두 지원합니다. 서버 전용 인증이 구성된 경우 채널이 설정될 때 서버는 공개 키 인증서를 제공합니다. 클라이언트는 서버의 루트 CA 인증서를 사용하여 서버를 인증합니다. 상호 인증이 구성된 경우, 클라이언트는 서버에 연결할 때 해당 인증서도 제공하고 서버는 인증서의 유효성을 검사합니다. 인증서 유효성 검사가 성공하면 클라이언트가 호출을 할 수 있습니다. 자체 인증 인증서도 허용되더라도 가장 강력한 보안을 위해 상호 인증을 구성하고 CA 서명 인증서를 사용하는 것이 좋습니다.

PKI(Public Key Infrastructure)는 공개 암호화 키의 배포 및 식별을 지원하여 사용자가 인터넷과 같은 네트워크를 통해 안전하게 데이터를 교환하고 상대방의 신원을 확인할 수 있도록 합니다. 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 주소와 함께 SAN(subjectAltName) IP 주소 확장 필드가 포함되어야 합니다.

서버와 클라이언트에는 각각 X.509 공개 키 인증서가 있어야 합니다.

클라이언트가 호스트 이름 대신 서버의 IP 주소에 연결하는 경우 서버의 인증서에는 서버의 IP 주소와 함께 SAN(subjectAltName) 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에 대한 호출 자격 증명을 전달하는 대신 주니퍼 Extension Toolkit jnx_authentication_service API를 사용하여 gRPC 세션 시작 시 디바이스에 한 번 로그인할 수 있으며 채널에서 실행되는 모든 후속 RPC가 인증됩니다. 주 니퍼 네트웍스 다운로드 사이트에서 JET 클라이언트 IDL 라이브러리를 다운로드할 수 있습니다.

기본적으로 Junos 디바이스는 인증된 gRPC 클라이언트가 모든 gRPC RPC를 실행할 수 있는 권한을 부여합니다. 선택적으로 gRPC 사용자의 로그인 클래스를 구성하여 특정 gRPC RPC를 명시적으로 허용하거나 거부할 수 있습니다. RPC를 지정하려면 and deny-grpc-rpc-regexps 문을 구성 allow-grpc-rpc-regexps 하고 RPC와 일치하는 정규식을 정의합니다. 자세한 내용은 gRPC RPC 권한 부여 구성을 참조하십시오.

X.509 인증서 획득

gRPC 세션은 X.509 공개 키 인증서를 사용하여 gRPC 서버 및 클라이언트를 인증합니다. 서버 전용 인증의 경우 gRPC 서버에 인증서가 있어야 합니다. 상호 인증의 경우 gRPC 서버와 클라이언트 모두에 인증서가 있어야 합니다. 인증서에 대한 요구 사항은 다음과 같습니다.

  • 인증서는 CA로 서명하거나 자체 서명할 수 있습니다.

  • 인증서는 PEM으로 인코딩되어야 합니다.

  • gRPC 서버의 인증서는 CN(일반 이름) 필드에서 gRPC 서버의 호스트 이름을 정의하거나 SAN(SubjectAltName) IP 주소 필드에서 gRPC 서버의 IP 주소를 정의해야 합니다. gRPC 클라이언트는 서버에 대한 연결을 설정하기 위해 동일한 값을 사용해야 합니다. 인증서가 SubjectAltName IP 주소를 정의하는 경우 인증 중에 일반 이름 필드가 무시됩니다.

OpenSSL을 사용하여 gRPC 서버의 인증서를 얻으려면:

  1. 프라이빗 키를 생성하고 키 길이를 비트 단위로 지정합니다.
  2. gRPC 클라이언트가 gRPC 서버의 IP 주소에 연결하는 경우 openssl.cnf 또는 이에 상응하는 구성 파일을 업데이트하여 gRPC 서버의 IP 주소로 확장자를 정의 subjectAltName=IP 합니다.
  3. 엔터티의 공개 키와 해당 ID에 대한 정보가 포함된 인증서 서명 요청(CSR)을 생성합니다.

    또는 단일 명령으로 CSR 정보를 제공할 수 있습니다. 예:

  4. 다음 중 하나를 수행하여 인증서를 생성합니다.

    • CSR을 CA로 전송하여 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 Socket Layer) 또는 TLS(전송 레이어 보안) 기술을 기반으로 하는 API 연결 설정을 사용합니다. 이러한 연결의 경우 gRPC 서버를 식별하는 로컬 인증서를 지정해야 합니다.

gRPC 서비스를 활성화하고 로컬 인증서를 지정하면 네트워크 디바이스는 서버 전용 인증을 사용합니다. 그런 다음 gRPC 서비스에 대한 상호 (양방향) 인증 구성에 설명된 단계를 완료하여 선택적으로 상호 인증를 구성할 수 있습니다.

gRPC 서비스를 위해 네트워크 디바이스를 구성하고 다음 계층 수준 중 하나에서 서버 인증에 사용되는 로컬 인증서를 지정할 수 있습니다.

  • [edit system services http servers]- 이 문 계층을 사용하여 고유한 포트에서 서로 다른 서비스 세트를 호스팅하는 하나 이상의 gRPC 서버를 구성할 수 있습니다. 또한 각 서버는 서로 다른 수신 대기 주소, 인증서 및 라우팅 인스턴스를 지원할 수 있습니다.

  • [edit system services extension-service request-response grpc ssl]- 동일한 수신 주소 및 포트에서 모든 gRPC 서비스를 지원하는 단일 gRPC 서버만 필요한 경우 이 문 계층을 사용합니다.

gRPC 서비스를 위한 디바이스를 구성하려면 사용자 환경의 요구 사항을 충족하는 계층 수준의 지침을 따릅니다.

[edit system services http servers]

계층 수준에서 하나 이상의 gRPC 서버를 구성하려면 다음을 수행합니다.[edit system services http servers]

  1. gRPC 서버 계층 수준으로 이동하여 서버의 식별자를 지정합니다.

    예를 들면 다음과 같습니다.

  2. gRPC 서비스에 사용할 포트를 구성합니다. 포트는 각 gRPC 서버에 대해 고유해야 합니다.

    예를 들면 다음과 같습니다.

  3. 이 서버에서 호스팅하는 gRPC 서비스를 구성합니다.

    이 예에서 서버는 gNMI 서비스 및 gNOI 서비스를 호스팅합니다.

  4. 클라이언트에 서버를 식별하는 로컬 인증서를 지정합니다.

    운영 모드 명령을 사용하여 request security pki local-certificate load 이전에 Junos PKI에 로드한 로컬 인증서의 식별자를 입력합니다.

    다음 예제에서는 로컬 인증서를 gnoi-server구성합니다.

  5. (선택 사항) 서버가 수신 연결을 수신하는 IPv4 또는 IPv6 주소를 지정합니다.

    예를 들면 다음과 같습니다.

    참고:

    IP 주소를 지정하지 않으면 기본 주소 ::가 수신 연결을 수신하는 데 사용됩니다.

  6. (선택 사항) 기본 라우팅 인스턴스와 다른 경우 이 gRPC 서버에 사용할 routing-instance를 구성합니다.

    다음 예제에서는 mgmt-junos 라우팅 인스턴스를 사용합니다.

  7. (선택 사항) 이 gRPC 서버가 지원하는 최대 연결 수를 구성합니다.

    다음 예제에서는 최대 10개의 연결을 구성합니다. 기본값은 5입니다.

  8. 구성을 커밋합니다.

서버 전용 인증 대신 상호 인증 구성하려면 gRPC 서비스에 대한 상호 (양방향) 인증 구성의 단계도 완료해야 합니다.

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

계층 수준에서 [edit system services extension-service request-response grpc ssl] 단일 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 live 운영 모드 명령을 사용합니다show trace application jsd.

  8. 구성을 커밋합니다.

서버 전용 인증 대신 상호 인증 구성하려면 gRPC 서비스에 대한 상호 (양방향) 인증 구성의 단계도 완료해야 합니다.

gRPC 서비스에 대한 상호 (양방향) 인증 구성

인증서를 사용하여 네트워크 디바이스를 gRPC 서버로 인증하고 NMS를 gRPC 클라이언트로 인증하는 gRPC 세션에 대한 상호 (양방향) 인증 구성할 수 있습니다. Junos 디바이스는 외부 클라이언트가 제공한 자격 증명을 사용하여 클라이언트를 인증하고 연결을 인증합니다.

다음 옵션 중 하나를 사용하여 Junos 디바이스에서 상호 인증을 구성할 수 있습니다.

  • 구성에서 직접 상호 인증 설정을 구성합니다.

  • 처음에는 서버 전용 인증을 설정한 다음 gNOI CertificateManagement 서비스를 사용하여 디바이스에 필요한 CA 인증서를 로드합니다.

디바이스 구성에서 직접 상호 인증을 구성하는 경우, 디바이스 구성은 gNOI 서비스를 사용하여 수행된 모든 설정보다 우선합니다.

시작하기 전에:

다음 섹션에서는 상호 인증을 구성하는 다양한 방법에 대해 설명합니다. 사용자 환경에 가장 적합한 방법을 사용할 수 있습니다.

디바이스 구성에서 상호 인증 구성

네트워크 디바이스 구성에서 직접 gRPC 클라이언트에 대한 인증을 구성하려면 다음을 수행합니다.

  1. 클라이언트 인증서의 유효성을 검사하는 데 사용할 루트 CA 인증서를 gRPC 서버 역할을 하는 로컬 디바이스에 다운로드합니다.

  2. 계층에서 클라이언트 인증서의 루트 CA에 대한 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

    인증서를 로드한 후 구성 모드로 들어가 상호 인증 구성을 계속합니다. 서버를 구성한 동일한 계층 수준에서 상호 인증을 구성해야 합니다. 계층 수준에 대한 섹션에 설명된 단계를 수행합니다.

[시스템 서비스 http 서버 편집]

계층 수준에서 [edit system services http servers] 구성된 서버에 대한 상호 인증 구성하기:

  1. 서버 구성 아래의 tls 문으로 이동합니다.

    예를 들면 다음과 같습니다.

  2. 상호 인증을 사용하도록 설정하고 클라이언트 인증서에 대한 요구 사항을 지정합니다.

    예를 들어, 인증서와 해당 유효성 검사가 필요한 가장 강력한 인증을 지정하려면 기본값이기도 한 을 사용합니다 request-and-require-cert-and-verify.

  3. 클라이언트 인증서를 확인하는 데 사용할 CA 프로필을 지정합니다.

    CA 프로필은 CA 프로필 구성의 2 단계에서 구성되었습니다.

    예를 들어, 라는 CA gnoi-client프로필을 지정하려면 다음과 같습니다.

  4. 구성을 커밋합니다.

[시스템 서비스 확장 서비스 요청-응답 grpc ssl 편집]

계층 수준에서 [edit system services extension-service request-response grpc ssl] 구성된 서버에 대한 상호 인증 구성하기:

  1. 상호 인증을 사용하도록 설정하고 클라이언트 인증서에 대한 요구 사항을 지정합니다.

    예를 들어 인증서와 해당 유효성 검사가 필요한 가장 강력한 인증을 지정하려면 를 사용합니다 require-certificate-and-verify.

    참고:

    기본값은 no-certificate입니다. 다른 옵션은 , request-certificate, request-certificate-and-verify, require-certificate, require-certificate-and-verify입니다.

    이 옵션은 테스트 환경에서만 사용하는 no-certificate 것이 좋습니다.

  2. 클라이언트 인증서를 확인하는 데 사용할 CA 프로필을 지정합니다.

    CA 프로필은 CA 프로필 구성의 2 단계에서 구성되었습니다.

    예를 들어, 라는 CA gnoi-client프로필을 지정하려면 다음과 같습니다.

  3. 구성을 커밋합니다.

gNOI CertificateManagement 서비스를 사용하여 상호 인증 구성

디바이스 구성에서 직접 설정을 구성하는 대신 gNOI CertificateManagement 서비스를 사용하여 gRPC 클라이언트와 gRPC 서버 간의 상호 인증을 설정할 수 있습니다. 처음에는 서버 전용 인증을 설정한 다음 gNOI CertificateManagement 서비스 RPC를 사용하여 클라이언트 CA 인증서를 로드합니다. gNOI 서비스를 사용하여 인증서를 로드하는 방법에 대한 자세한 내용은 gNOI CertificateManagement 인증서 관리 서비스를 참조하십시오.

gRPC 서버는 gNOI 서비스에 대해 하나의 글로벌 CA 인증서 번들만 지원합니다. gNOI CertificateManagement 서비스를 사용하여 CA 인증서 번들을 로드할 때 디바이스는 암시적으로 상호 인증을 사용합니다. 그러나 다음 사항에 유의해야 합니다.

  • CertificateManagement 서비스는 항상 예약된 식별자를 gnoi-ca-bundle사용하여 CA 인증서 번들을 로드합니다ca-profile-group.

  • 서비스를 사용하여 CertificateManagement CA 인증서 번들을 로드하는 경우 디바이스는 암시적으로 상호 인증을 사용합니다.

  • CertificateManagement 서비스가 새 CA 인증서 번들을 로드하도록 요청을 보내면 서버는 디바이스에서 이전 CA 번들에 대한 인증서를 지우고 새 인증서를 로드합니다.

  • 서비스를 사용하여 CertificateManagement CA 인증서 번들을 로드하고 디바이스 구성에서 상호 인증도 명시적으로 구성하는 경우 구성된 문이 우선합니다.

gRPC 서비스에 대한 사용자 계정 구성

채널 자격 증명은 gRPC 채널에 연결되며 클라이언트 애플리케이션이 서비스에 액세스할 수 있도록 합니다. 호출 자격 증명은 특정 RPC 요청에 연결되며 클라이언트 응용 프로그램을 사용하는 사용자에 대한 정보를 제공합니다. 네트워크 디바이스에 대한 사용자 계정이 필요한 각 RPC 요청에서 호출 자격 증명을 제공해야 합니다. 사용자는 네트워크 디바이스에서 로컬로 정의된 사용자 계정을 가지고 있어야 하며, 또는 TACACS+ 서버에서 사용자를 인증해야 하며, TACACS+ 서버는 디바이스에서 로컬로 정의된 사용자 템플릿 계정에 사용자를 매핑합니다.

사용자 계정을 생성하려면 다음을 수행합니다.

  1. 고유한 사용자 이름으로 문을 구성 user 하고 사용자가 수행하는 모든 작업에 필요한 권한이 있는 로그인 클래스를 지정하는 문을 포함 class 합니다. 예를 들면 다음과 같습니다.
  2. 로컬 사용자 계정의 경우 사용자의 비밀번호를 구성합니다.

    사용자는 원격 인증 서버를 통해 인증되므로 로컬 사용자 템플릿 계정의 비밀번호를 생략할 수 인증할 수 있습니다.

  3. (선택 사항) 사용자 이름을 지정하도록 문을 구성 full-name 합니다.
  4. 구성을 커밋하여 디바이스에서 사용자 계정을 활성화합니다.
  5. gRPC 클라이언트가 gRPC 세션에서 RPC를 실행할 각 네트워크 디바이스에서 이전 단계를 반복합니다.

gRPC RPC 권한 부여 구성

기본적으로 Junos 디바이스는 인증된 gRPC 클라이언트가 모든 gRPC RPC를 실행할 수 있는 권한을 부여합니다. gRPC RPC를 명시적으로 허용하거나 거부하도록 Junos 로그인 클래스를 구성할 수 있습니다. RPC를 지정하려면 and deny-grpc-rpc-regexps 문을 구성 allow-grpc-rpc-regexps 하고 RPC와 일치하는 정규식을 정의합니다. 허용 및 거부 목록에 충돌하는 표현식이 있는 경우 거부 목록이 우선합니다. RPC가 어느 목록과도 일치하지 않으면 RPC가 기본적으로 허용됩니다.

Junos 디바이스는 gRPC RPC를 지정하기 위해 다음 구문을 사용합니다.

여기서 package, service, 및 rpc 는 해당 서비스의 프로토 정의 파일에 있는 해당 문에 정의된 이름입니다. 예를 들면 다음과 같습니다.

하나 이상의 표현식으로 여러 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 서비스뿐만 아니라 서비스에 대한 gRIBI 모든 RPC도 거부합니다.

  4. 적절한 gRPC 사용자에게 로그인 클래스를 할당합니다.

    예를 들어, 다음 명령문은 사용자에게 클래스를 grpc-operator 할당합니다.grpc-user

네트워크 디바이스에서 gRPC 서비스를 활성화한 후 원격 NMS를 gRPC 클라이언트로 설정합니다. 클라이언트가 gNOI 작업을 실행할 수 있도록 하려면 gNOI 서비스 구성에 설명된 대로 클라이언트를 구성합니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.

출시
설명
25.2R1 및 25.2R1-EVO
Junos OS 릴리스 25.2R1 및 Junos OS Evolved 릴리스 25.2R1부터는 고유한 포트에서 서로 다른 서비스 세트를 호스팅하는 여러 gRPC 서버를 구성할 수 있습니다.