비공개 CA로 상호 TLS 설정

이 페이지에서는 Certificate Authority Service를 사용하고 인증서 관리자 TrustConfig 리소스에 인증서를 업로드하여 비공개 인증 기관(CA)을 만드는 방법을 설명합니다.

또한 애플리케이션 부하 분산기에 대해 상호 TLS를 구성하는 데 필요한 네트워크 보안 리소스를 만듭니다.

시작하기 전에

  • 상호 TLS 개요를 검토합니다.
  • Google Cloud CLI 설치 이 도구에 대한 전체 개요는 gcloud CLI 개요를 참조하세요. 부하 분산과 관련된 명령어는 API 및 gcloud GLI 참조에서 확인할 수 있습니다.

    이전에 gcloud CLI를 실행한 적이 없으면 먼저 gcloud init를 실행하여 인증하세요.

  • CA 풀을 만드는 방법을 알아야 합니다.

  • 전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기를 사용하는 경우에는 다음과 같은 지원되는 백엔드 중 하나를 사용하여 부하 분산기를 설정했는지 확인합니다.

    • VM 인스턴스 그룹 백엔드
    • Cloud Storage 버킷(백엔드 버킷 외에도 부하 분산기에 연결된 백엔드 서비스가 하나 이상 있는 경우에만 지원됨)
    • Cloud Run, App Engine 또는 Cloud Run Functions
    • 하이브리드 연결
  • 리전 외부 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기를 사용하는 경우에는 다음과 같은 지원되는 백엔드 중 하나를 사용하여 부하 분산기를 설정했는지 확인합니다.

    • VM 인스턴스 그룹 백엔드
    • Cloud Run
    • 하이브리드 연결

권한

이 가이드를 완료하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 프로젝트에 부여해 달라고 요청하세요.

  • TargetHTTPProxy와 같은 부하 분산기 리소스 만들기: Compute 부하 분산기 관리자(roles/compute.loadBalancerAdmin)
  • 인증서 관리자 리소스 사용하기: 인증서 관리자 소유자(roles/certificatemanager.owner)
  • 보안 및 네트워킹 구성요소 만들기: Compute 네트워크 관리자(roles/compute.networkAdmin) 및 Compute 보안 관리자(roles/compute.securityAdmin)
  • 프로젝트 만들기(선택사항): 프로젝트 생성자(roles/resourcemanager.projectCreator)

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

비공개 CA 만들기

CA 서비스를 사용하여 비공개 CA를 만든 다음 루트 인증서를 만듭니다.

  1. CA 풀을 만들려면 gcloud privateca pools create 명령어를 사용합니다.

    gcloud privateca pools create CA_POOL \
       --location=us-central1
    

    CA_POOL을 상위 CA 풀의 ID 또는 이름으로 바꿉니다.

  2. CA 풀에 비공개 CA를 만들려면 gcloud privateca roots create 명령어를 사용합니다.

    gcloud privateca roots create CA_ROOT \
       --pool=CA_POOL \
       --subject="CN=my-ca, O=Test LLC" \
       --location=us-central1
    

    다음을 바꿉니다.

    • CA_ROOT: 비공개 CA의 ID 또는 이름입니다.
    • CA_POOL: 상위 CA 풀의 ID 또는 이름입니다.
  3. 새 CA를 설명하고 root.cert 파일을 만들려면 gcloud privateca roots describe 명령어를 사용합니다.

    gcloud privateca roots describe CA_ROOT \
       --pool=CA_POOL \
       --location=us-central1 \
       --format='value(pemCaCertificates)' > root.cert
    
    export ROOT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

    다음을 바꿉니다.

    • CA_ROOT: 비공개 CA의 ID 또는 이름입니다.
    • CA_POOL: 상위 CA 풀의 ID 또는 이름입니다.

    자세한 내용은 다음을 참조하세요.

비공개 CA로 TrustConfig 만들기

비공개 CA를 사용하여 생성된 루트 인증서를 사용하여 PKI를 나타내는 인증서 관리자 TrustConfig 리소스를 만듭니다. TrustConfig 리소스는 루트 인증서를 나타내는 단일 신뢰 앵커가 포함된 간단한 트러스트 저장소라고 가정합니다.

다음 단계에서 TRUST_CONFIG_NAMETrustConfig 리소스의 이름으로 바꿉니다.

  • trust_config.yaml 파일을 만들려면 다음 명령어를 사용합니다.

    cat << EOF > trust_config.yaml
    name: TRUST_CONFIG_NAME
    trustStores:
    - trustAnchors:
       - pemCertificate: "${ROOT?}"
    EOF
    
  • 인증서 관리자 TrustConfig 리소스를 만들려면 gcloud certificate-manager trust-configs import 명령어를 사용합니다.

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=REGION
    

    다음을 바꿉니다.

    REGION: 리전 간 내부 애플리케이션 부하 분산기, 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기에 대해 global을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.

클라이언트 인증 리소스 만들기

클라이언트 인증(ServerTLSPolicy라고도 함) 리소스를 사용하면 클라이언트 인증서 유효성을 검사할 때 사용할 서버 측 TLS 모드와 TrustConfig 리소스를 지정할 수 있습니다. 클라이언트가 부하 분산기에 잘못된 인증서를 제공하거나 인증서를 제공하지 않으면 clientValidationMode는 클라이언트 연결이 처리되는 방법을 지정합니다. 자세한 내용은 MTLS 클라이언트 검증 모드를 참조하세요.

  • clientValidationModeALLOW_INVALID_OR_MISSING_CLIENT_CERT로 설정되면 검증이 실패하거나 클라이언트 인증서가 없는 경우에도 모든 요청이 백엔드로 전달됩니다.
  • clientValidationModeREJECT_INVALID로 설정되면 TrustConfig 리소스에 대해 검증할 수 있는 클라이언트 인증서를 제공하는 요청만 백엔드로 전달됩니다.

ServerTLSPolicy 저장소를 만들려면 다음 단계를 완료하세요.

  1. 연결을 처리하는 방법에 따라 다음 옵션 중 하나를 선택합니다.

    다음 단계에서 SERVER_TLS_POLICY_NAME을 서버 TLS 정책의 이름으로 바꾸고 PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.

    • 옵션 1: clientValidationModeALLOW_INVALID_OR_MISSING_CLIENT_CERT로 설정되어 있습니다.

      server_tls_policy.yaml 파일을 만들려면 다음 명령어를 사용합니다.

      전역

      외부 애플리케이션 부하 분산기와 리전 간 내부 애플리케이션 부하 분산기의 경우 다음 명령어를 사용합니다.

      cat << EOF > server_tls_policy.yaml
      name: SERVER_TLS_POLICY_NAME
      mtlsPolicy:
        clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
        clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
      EOF
      

      리전

      리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우 다음 명령어를 사용합니다.

      cat << EOF > server_tls_policy.yaml
      name: SERVER_TLS_POLICY_NAME
      mtlsPolicy:
        clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
        clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
      EOF
      
    • 옵션 2: clientValidationModeREJECT_INVALID로 설정되어 있습니다.

      server_tls_policy.yaml 파일을 만들려면 다음 명령어를 사용합니다.

      전역

      외부 애플리케이션 부하 분산기와 리전 간 내부 애플리케이션 부하 분산기의 경우 다음 명령어를 사용합니다.

      cat << EOF > server_tls_policy.yaml
      name: SERVER_TLS_POLICY_NAME
      mtlsPolicy:
        clientValidationMode: REJECT_INVALID
        clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
      EOF
      

      리전

      리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우 다음 명령어를 사용합니다.

      cat << EOF > server_tls_policy.yaml
      name: SERVER_TLS_POLICY_NAME
      mtlsPolicy:
        clientValidationMode: REJECT_INVALID
        clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
      EOF
      
  2. ServerTlsPolicy 리소스를 만들려면 gcloud network-security server-tls-policies import 명령어를 사용합니다.

    전역

    외부 애플리케이션 부하 분산기와 리전 간 내부 애플리케이션 부하 분산기의 경우 다음 명령어를 사용합니다.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
      --source=server_tls_policy.yaml \
      --location=global
    

    리전

    리전 외부 애플리케이션 부하 분산기와 리전 내부 애플리케이션 부하 분산기의 경우 다음 명령어를 사용합니다.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
      --source=server_tls_policy.yaml \
      --location=REGION
    
  3. (선택사항) 현재 프로젝트의 지정된 위치에 있는 모든 클라이언트 인증(ServerTlsPolicies) 리소스를 나열합니다.

    콘솔

    1. Google Cloud 콘솔에서 클라이언트 인증 페이지로 이동합니다.

      클라이언트 인증으로 이동

    2. 모든 ServerTlsPolicies 리소스가 표시됩니다.

    gcloud

    모든 클라이언트 인증(ServerTlsPolicies) 리소스를 나열하려면 gcloud network-security server-tls-policies list 명령어를 사용합니다.

    gcloud network-security server-tls-policies list \
      --location=REGION
    

    다음을 바꿉니다.

    REGION: 리전 간 내부 애플리케이션 부하 분산기, 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기에 대해 global을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.

부하 분산기에 mTLS 설정

상호 TLS 인증이 작동하게 하려면 부하 분산기를 설정한 후 ServerTLSPolicy 리소스를 사용하여 대상 HTTPS 프록시를 업데이트해야 합니다.

  1. 클라이언트 인증(ServerTLSPolicy) 리소스를 이미 만들었는지 확인합니다. 자세한 내용은 클라이언트 인증 리소스 만들기를 참조하세요.

  2. 프로젝트의 모든 대상 HTTPS 프록시를 나열하려면 gcloud compute target-https-proxies list 명령어를 사용합니다.

    gcloud compute target-https-proxies list
    

    ServerTLSPolicy 리소스를 연결할 대상 HTTPS 프록시의 이름을 기록해 둡니다. 다음 단계에서는 이 이름을 TARGET_HTTPS_PROXY_NAME이라고 합니다.

  3. 대상 HTTPS 프록시 구성을 파일로 내보내려면 gcloud compute target-https-proxies export 명령어를 사용합니다.

    전역

      gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
          --destination=TARGET_PROXY_FILENAME \
          --global
      

    다음을 바꿉니다.

    • TARGET_HTTPS_PROXY_NAME: 대상 프록시 이름
    • TARGET_PROXY_FILENAME: yaml 파일의 이름. 예를 들면 mtls_target_proxy.yaml입니다.

    리전

     gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
         --destination=TARGET_PROXY_FILENAME \
         --region=REGION
     

    다음을 바꿉니다.

    • TARGET_HTTPS_PROXY_NAME: 대상 프록시 이름
    • TARGET_PROXY_FILENAME: yaml 파일의 이름. 예를 들면 mtls_target_proxy.yaml입니다.
    • REGION: 부하 분산기를 구성한 리전
  4. 현재 프로젝트의 지정된 위치에 있는 모든 ServerTlsPolicies 리소스를 나열합니다.

    콘솔

    1. Google Cloud 콘솔에서 클라이언트 인증 페이지로 이동합니다.

      클라이언트 인증으로 이동

    2. 모든 ServerTlsPolicies 리소스가 표시됩니다.

    gcloud

    모든 클라이언트 인증(ServerTlsPolicies) 리소스를 나열하려면 gcloud network-security server-tls-policies list 명령어를 사용합니다.

    gcloud network-security server-tls-policies list \
      --location=REGION
    

    다음을 바꿉니다.

    REGION: 리전 간 내부 애플리케이션 부하 분산기, 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기에 대해 global을 사용합니다. 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 부하 분산기를 구성한 리전을 사용합니다.

    mTLS를 구성하려면 ServerTlsPolicies 리소스 이름을 기록해 둡니다. 이 이름은 다음 단계에서 SERVER_TLS_POLICY_NAME이라고 합니다.

  5. ServerTlsPolicy 리소스 파일 TARGET_PROXY_FILENAME을 추가하려면 다음 명령어를 사용합니다. PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.

    echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME
  6. 파일에서 대상 HTTPS 프록시 구성을 가져오려면 gcloud compute target-https-proxies import 명령어를 사용합니다.

    전역

       gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
           --source=TARGET_PROXY_FILENAME \
           --global
       

    다음을 바꿉니다.

    • TARGET_HTTPS_PROXY_NAME: 대상 프록시 이름
    • TARGET_PROXY_FILENAME: yaml 파일의 이름. 예를 들면 mtls_target_proxy.yaml입니다.

    리전

       gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
           --source=TARGET_PROXY_FILENAME \
           --region=REGION
       

    다음을 바꿉니다.

    • TARGET_HTTPS_PROXY_NAME: 대상 프록시 이름
    • TARGET_PROXY_FILENAME: yaml 파일의 이름. 예를 들면 mtls_target_proxy.yaml입니다.
    • REGION: 부하 분산기를 구성한 리전

mTLS 커스텀 헤더 추가

mTLS를 사용 설정하면 커스텀 헤더를 사용하여 mTLS 연결에 대한 정보를 전달할 수 있습니다. 또한 mTLS 연결 실패가 로그에 캡처되도록 로깅을 사용 설정할 수 있습니다.

백엔드 서비스에 mTLS 커스텀 헤더 추가

전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기의 경우 커스텀 헤더를 사용하여 mTLS 연결에 대한 정보를 백엔드 서비스에 전달할 수 있습니다.

  1. 프로젝트의 모든 백엔드 서비스를 나열하려면 gcloud compute backend-services list 명령어를 사용합니다.

    gcloud compute backend-services list
    

    커스텀 헤더 및 로깅을 사용 설정하려면 백엔드 서비스의 이름을 기록해 둡니다. 이 이름은 다음 단계에서 BACKEND_SERVICE로 참조합니다.

  2. 백엔드 서비스를 업데이트하려면 gcloud compute backend-services update 명령어를 사용합니다.

    gcloud compute backend-services update BACKEND_SERVICE \
      --global \
      --enable-logging \
      --logging-sample-rate=1 \
      --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
      --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
      --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
      --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
      --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
      --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
      --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
      --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
      --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
      --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'
    

URL 맵에 mTLS 커스텀 헤더 추가

리전 간 내부 애플리케이션 부하 분산기, 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 경우 커스텀 헤더를 사용하여 mTLS 연결에 대한 정보를 URL 맵에 전달할 수 있습니다.

프로젝트의 모든 URL 맵을 나열하려면 gcloud compute url-maps list 명령어를 사용합니다.

   gcloud compute url-maps list
   

커스텀 헤더와 로깅을 사용 설정하려면 URL 맵의 이름을 기록해 둡니다. 이 이름은 다음 단계에서 URL_MAP_NAME로 참조됩니다.

전역

리전 간 내부 애플리케이션 부하 분산기의 URL 맵을 수정하려면 gcloud compute url-maps edit 명령어를 사용합니다.

   gcloud compute url-maps edit URL_MAP_NAME --global
   

다음은 커스텀 요청 헤더(requestHeadersToAdd)에서 변수를 사용하는 방법을 보여주는 샘플 YAML 파일입니다. 같은 변수를 사용하여 커스텀 응답 헤더(responseHeadersToAdd)를 전송할 수 있습니다.

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

리전

리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 URL 맵을 수정하려면 gcloud compute url-maps edit 명령어를 사용합니다.

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION
   

다음은 커스텀 요청 헤더(requestHeadersToAdd)에서 변수를 사용하는 방법을 보여주는 샘플 YAML 파일입니다. 같은 변수를 사용하여 커스텀 응답 헤더(responseHeadersToAdd)를 전송할 수 있습니다.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

다음 단계