Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의 내용
 

gRPC 서비스 구성

요약 클라이언트가 gNOI(네트워크 운영 인터페이스) 서비스, gRPC 네트워크 관리 인터페이스(gNMI) 서비스 및 gRPC gRIBI(라우팅 정보 기반 인터페이스) 서비스를 포함하여 네트워크 디바이스에서 gRPC 서비스를 사용할 수 있도록 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 표준은 인증서의 형식을 정의합니다. 디지털 인증서는 인증서 유효성 검사를 통해 두 끝점 간에 보안 연결을 설정하는 데 사용할 수 있습니다. gRPC 채널을 설정하려면 인증이 필요한 각 엔드포인트(디바이스 또는 애플리케이션)가 교환에 X.509 인증서를 제공해야 합니다.

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

PKI(공개 키 인프라)는 공개 암호화 키의 배포 및 식별을 지원하여 사용자가 인터넷과 같은 네트워크를 통해 데이터를 안전하게 교환하고 상대방의 신원을 확인할 수 있도록 합니다. 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+ 서버에 의해 인증되어야 하며, TACACS+ 서버는 사용자를 디바이스에서 로컬로 정의된 사용자 템플릿 계정에 매핑해야 합니다. RPC의 인수에 호출 자격 증명(사용자 이름 및 암호)을 metadata 제공할 수 있습니다. 인증에 성공하면 Junos 디바이스는 지정된 사용자의 계정 권한을 사용하여 RPC 요청을 실행합니다.

참고:

Junos 디바이스에서 실행되는 모든 RPC에 대한 호출 자격 증명을 전달하는 대신, 주니퍼 확장 툴킷 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 서버의 인증서는 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을 인증 기관에 보내 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) 기술을 기반으로 하는 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 서비스에 대한 상호(양방향) 인증 구성

gRPC 세션에 대한 상호(양방향) 인증을 구성할 수 있으며, 이는 네트워크 디바이스를 gRPC 서버로 인증하고 네트워크 관리 시스템을 SSL 인증서를 사용하여 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 CertificateManagagment 서비스를 사용하여 디바이스 구성에서 직접 설정을 구성하는 대신 gRPC 클라이언트와 gRPC 서버 간의 상호 인증을 설정할 수 있습니다. 처음에는 서버 전용 인증을 설정한 다음 gNOI CertificateManagement 서비스 RPC를 사용하여 클라이언트 CA 인증서를 로드합니다. gNOI 서비스를 사용하여 인증서를 로드하는 방법에 대한 자세한 내용은 gNOI CertificateManagagment 인증서 관리 서비스를 참조하세요.

gRPC 서버는 gNOI 서비스에 대해 하나의 글로벌 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+ 서버에 의해 인증되어야 하며, 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 는 해당 서비스의 프로토타입 정의 파일에 있는 각 문에 정의된 이름입니다. 예를 들어:

하나 이상의 표현식으로 여러 allow-grpc-rpc-regexps 및 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 서비스를 사용하도록 설정한 후 원격 네트워크 관리 시스템을 gRPC 클라이언트로 설정합니다. 클라이언트가 gNOI 작업을 실행할 수 있도록 하려면 gNOI 서비스 구성에 설명된 대로 클라이언트를 구성합니다.