프록시리스 gRPC로 서비스 보안 설정

이 가이드에서는 프록시리스 gRPC 서비스 메시에 보안 서비스를 구성하는 방법을 설명합니다.

요구사항

gRPC 프록시리스 서비스 메시의 서비스 보안을 구성하기 전에 다음 요구사항을 충족하는지 확인하세요.

Identity and Access Management 구성

Google Kubernetes Engine을 사용하는 데 필요한 권한이 있어야 합니다. 최소한 다음과 같은 역할이 있어야 합니다.

  • roles/container.clusterAdmin GKE 역할
  • roles/compute.instanceAdmin Compute Engine 역할
  • roles/iam.serviceAccountUser 역할

설정에 필요한 리소스를 만들려면 compute.NetworkAdmin 역할을 가져야 합니다. 이 역할에는 필요한 리소스를 생성, 업데이트, 삭제, 나열, 사용(해당 리소스를 다른 리소스에서 참조)하는 데 필요한 모든 권한이 포함되어 있습니다. 프로젝트의 소유자-편집자에게는 자동으로 이 역할이 부여됩니다.

백엔드 서비스 리소스에서 이러한 리소스를 참조할 때는 networksecurity.googleapis.com.clientTlsPolicies.usenetworksecurity.googleapis.com.serverTlsPolicies.use가 적용되지 않습니다.

향후에 적용되고 compute.NetworkAdmin 역할을 사용하는 경우 이 검사가 시행되면 어떤 문제도 발견되지 않습니다.

커스텀 역할을 사용 중이고 나중에 이 검사가 시행되는 경우 각 .use 권한을 포함해야 합니다. 그렇지 않으면 향후 커스텀 역할에 백엔드 서비스에서 clientTlsPolicy 또는 serverTlsPolicy를 참조하는 데 필요한 권한이 없을 수 있습니다.

설정 준비

프록시리스 서비스 메시(PSM) 보안은 프록시리스 gRPC 서비스 문서에 따라 부하 분산용으로 설정된 서비스 메시에 대한 보안을 강화합니다. 프록시리스 서비스 메시에서 gRPC 클라이언트는 URI의 xds: 스킴을 사용하여 PSM 부하 분산과 엔드포인트 검색 기능을 사용 설정하는 서비스에 액세스합니다.

gRPC 클라이언트 및 서버를 올바른 버전으로 업데이트

사용 중인 언어에 지원되는 최소 gRPC 버전을 사용하여 애플리케이션을 빌드하거나 다시 빌드하세요.

부트스트랩 파일 업데이트

gRPC 애플리케이션은 단일 부트스트랩 파일을 사용하므로 gRPC 클라이언트 및 서버 측 코드에 필요한 모든 필드가 있어야 합니다. 부트스트랩 생성기는 PSM 보안에 필요한 플래그와 값을 포함하도록 부트스트랩 파일을 자동으로 생성합니다. 자세한 내용은 샘플 부트스트랩 파일이 포함된 부트스트랩 파일 섹션을 참조하세요.

설정 개요

이 설정 프로세스는 GKE 및 프록시리스 gRPC 서비스를 사용하는 Cloud Service Mesh 설정 확장 프로그램입니다. 설정 단계의 수정되지 않은 기존 단계는 적용되는 위치에 관계없이 참조됩니다.

GKE를 사용하는 Cloud Service Mesh 설정의 주요 개선사항은 다음과 같습니다.

  1. 비공개 CA 풀과 필수 인증 기관을 만드는 CA 서비스 설정
  2. GKE용 워크로드 아이덴티티 제휴, 메시 인증서 기능, CA 서비스 통합으로 GKE에서 GKE 클러스터 만들기
  3. 클러스터에서 메시 인증서 발급 구성
  4. 클라이언트 및 서버 서비스 계정 만들기
  5. xDS API 및 xDS 서버 사용자 인증 정보를 사용하는 예시 서버를 설정하여 Cloud Service Mesh에서 보안 구성 가져오기
  6. xDS 사용자 인증 정보를 사용하는 예시 클라이언트 설정
  7. 보안 구성이 포함되도록 Cloud Service Mesh 구성 업데이트

xDS 사용자 인증 정보를 사용하는 코드 예시를 다음 위치에서 확인할 수 있습니다.

Google Cloud CLI 업데이트

Google Cloud CLI를 업데이트하려면 다음 명령어를 실행합니다.

gcloud components update

환경 변수 설정

이 가이드에서는 Cloud Shell 명령어를 사용하며, 명령어의 반복 정보는 다양한 환경 변수로 표시됩니다. 명령어를 실행하기 전에 특정 값을 셸 환경에서 다음 환경 변수로 설정합니다. 각 주석 행은 연관된 환경 변수의 의미를 나타냅니다.

# Your project ID
PROJECT_ID=PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME=CLUSTER_NAME
ZONE=ZONE
gcloud config set compute/zone $ZONE

# GKE cluster URL derived from the above
GKE_CLUSTER_URL="https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${ZONE}/clusters/${CLUSTER_NAME}"

# Workload pool to be used with the GKE cluster
WORKLOAD_POOL="${PROJECT_ID}.svc.id.goog"

# Kubernetes namespace to run client and server demo.
K8S_NAMESPACE='default'
DEMO_BACKEND_SERVICE_NAME='grpc-gke-helloworld-service'

# Compute other values
# Project number for your project
PROJNUM=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

# VERSION is the GKE cluster version. Install and use the most recent version
# from the rapid release channel and substitute its version for
# CLUSTER_VERSION, for example:
# VERSION=latest available version
# Note that the minimum required cluster version is 1.21.4-gke.1801.
VERSION="CLUSTER_VERSION"
SA_GKE=service-${PROJNUM}@container-engine-robot.iam.gserviceaccount.com

필요한 API에 대한 액세스 사용 설정

이 섹션에서는 필요한 API에 대한 액세스를 사용 설정하는 방법을 설명합니다.

  1. 다음 명령어를 실행하여 프록시리스 gRPC 서비스 메시 보안에 필요한 Cloud Service Mesh 및 기타 API를 사용 설정합니다.

    gcloud services enable \
        container.googleapis.com \
        cloudresourcemanager.googleapis.com \
        compute.googleapis.com \
        trafficdirector.googleapis.com \
        networkservices.googleapis.com \
        networksecurity.googleapis.com \
        privateca.googleapis.com \
        gkehub.googleapis.com
    
  2. 다음 명령어를 실행하여 기본 서비스 계정에서 Cloud Service Mesh 보안 API에 액세스하도록 허용합니다.

    GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
        --filter='displayName:Compute Engine default service account')
    
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
      --member serviceAccount:${GSA_EMAIL} \
       --role roles/trafficdirector.client
    

GKE 클러스터 만들기 또는 업데이트

Cloud Service Mesh 서비스 보안은 GKE와의 CA 서비스 통합에 따라 달라집니다. GKE 클러스터는 설정 요구사항 외에도 다음 요구사항을 충족해야 합니다.

  • 최소 클러스터 버전 1.21.4-gke.1801을 사용합니다. 이후 버전의 기능이 필요한 경우 빠른 출시 채널에서 해당 버전을 가져올 수 있습니다.
  • 인증서를 발급하는 인증 기관 만들기의 설명대로 메시 인증서로 GKE 클러스터를 사용 설정하고 구성해야 합니다.
  1. GKE용 워크로드 아이덴티티 제휴를 사용하는 새 클러스터를 만듭니다. 기존 클러스터를 업데이트하는 경우 다음 단계로 건너뜁니다. --tags에 지정된 값은 Cloud Load Balancing 구성요소로 Cloud Service Mesh 구성 섹션에 있는 firewall-rules create 명령어에 대한 --target-tags 플래그로 전달되는 이름과 일치해야 합니다.

    # Create a GKE cluster with GKE managed mesh certificates.
    gcloud container clusters create CLUSTER_NAME \
      --release-channel=rapid \
      --scopes=cloud-platform \
      --image-type=cos_containerd \
      --machine-type=e2-standard-2 \
      --zone=ZONE \
      --workload-pool=PROJECT_ID.svc.id.goog \
      --enable-mesh-certificates \
      --cluster-version=CLUSTER_VERSION \
      --enable-ip-alias \
      --tags=allow-health-checks \
      --workload-metadata=GKE_METADATA
    

    클러스터 생성이 완료되는 데 몇 분 정도 걸릴 수 있습니다.

  2. 기존 클러스터를 사용하는 경우 GKE용 워크로드 아이덴티티 제휴 및 GKE 메시 인증서를 사용 설정합니다. 클러스터가 update 명령어와 함께 사용할 수 없는 --enable-ip-alias 플래그로 생성되었는지 확인합니다.

    gcloud container clusters update CLUSTER_NAME \
      --enable-mesh-certificates
    
  3. 다음 명령어를 실행하여 kubectl 명령어의 기본 클러스터로 새 클러스터로 전환합니다.

    gcloud container clusters get-credentials CLUSTER_NAME \
      --zone ZONE
    

Fleet에 클러스터 등록

GKE 클러스터 만들기에서 만들거나 업데이트한 클러스터를 Fleet에 등록합니다. 클러스터를 등록하면 여러 프로젝트에서 클러스터를 더욱 간편하게 구성할 수 있습니다.

이 단계를 완료하는 데 각각 최대 10분이 걸릴 수 있습니다.

  1. Fleet에 클러스터를 등록합니다.

    gcloud container fleet memberships register CLUSTER_NAME \
      --gke-cluster=ZONE/CLUSTER_NAME \
      --enable-workload-identity --install-connect-agent \
      --manifest-output-file=MANIFEST-FILE_NAME
    

    변수를 다음과 같이 바꿉니다.

    • CLUSTER_NAME: 클러스터 이름
    • ZONE: 클러스터의 영역
    • MANIFEST-FILE_NAME: 이 명령어가 등록을 위해 매니페스트를 생성하는 경로

    등록 프로세스가 성공하면 다음과 같은 메시지가 표시됩니다.

    Finished registering the cluster CLUSTER_NAME with the fleet.
  2. 생성된 매니페스트 파일을 클러스터에 적용합니다.

    kubectl apply -f MANIFEST-FILE_NAME
    

    애플리케이션 프로세스가 성공하면 다음과 같은 메시지가 표시됩니다.

    namespace/gke-connect created
    serviceaccount/connect-agent-sa created
    podsecuritypolicy.policy/gkeconnect-psp created
    role.rbac.authorization.k8s.io/gkeconnect-psp:role created
    rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created
    role.rbac.authorization.k8s.io/agent-updater created
    rolebinding.rbac.authorization.k8s.io/agent-updater created
    role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
    clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
    clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created
    clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created
    rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created
    role.rbac.authorization.k8s.io/gke-connect-namespace-getter created
    rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created
    secret/http-proxy created
    deployment.apps/gke-connect-agent-20210416-01-00 created
    service/gke-connect-monitoring created
    secret/creds-gcp create
    
  3. 클러스터에서 멤버십 리소스를 가져옵니다.

    kubectl get memberships membership -o yaml
    

    출력에는 Fleet에서 할당한 워크로드 아이덴티티 풀이 포함되어야 합니다. 여기서 PROJECT_ID는 프로젝트 ID입니다.

    workload_identity_pool: PROJECT_ID.svc.id.goog
    

    이는 클러스터가 성공적으로 등록되었음을 의미합니다.

인증서 발급을 위한 인증 기관 만들기

포드에 인증서를 발급하려면 CA 서비스 풀과 다음 인증 기관(CA)을 만듭니다.

  • 루트 CA. 모든 발급된 메시 인증서의 신뢰할 수 있는 루트입니다. 기존 루트 CA가 있으면 사용해도 됩니다. 소규모의 장기 인증서 발급을 위한 enterprise 등급에서 루트 CA를 만듭니다.
  • 하위 CA 이 CA는 워크로드의 인증서를 발급합니다. 클러스터가 배포된 리전에 하위 CA를 만드세요. 대규모의 단기 인증서 발급을 위한 devops 등급에서 하위 CA를 만듭니다.

하위 CA를 만드는 것은 선택사항이지만 루트 CA를 사용하여 GKE 메시 인증서를 발급하는 대신 하위 CA를 만드는 것이 좋습니다. 루트 CA를 사용하여 메시 인증서를 발급하려는 경우 기본 구성 기반 발급 모드가 계속 허용되는지 확인하세요.

하위 CA는 클러스터와 다른 리전에 있을 수 있지만 클러스터와 동일한 리전에 만들어 성능을 최적화하는 것이 좋습니다. 그러나 성능이나 가용성에 영향을 주지 않고 다른 리전에 루트 및 하위 CA를 만들 수 있습니다.

CA 서비스에 지원되는 리전은 다음과 같습니다.

리전 이름 리전 설명
asia-east1 타이완
asia-east2 홍콩
asia-northeast1 도쿄
asia-northeast2 오사카
asia-northeast3 서울
asia-south1 뭄바이
asia-south2 델리
asia-southeast1 싱가포르
asia-southeast2 자카르타
australia-southeast1 시드니
australia-southeast2 멜버른
europe-central2 바르샤바
europe-north1 핀란드
europe-southwest1 마드리드
europe-west1 벨기에
europe-west2 런던
europe-west3 프랑크푸르트
europe-west4 네덜란드
europe-west6 취리히
europe-west8 밀라노
europe-west9 파리
europe-west10 베를린
europe-west12 토리노
me-central1 도하
me-central2 Dammam
me-west1 텔아비브
northamerica-northeast1 몬트리올
northamerica-northeast2 토론토
southamerica-east1 상파울루
southamerica-west1 산티아고
us-central1 아이오와
us-east1 사우스캐롤라이나
us-east4 북 버지니아
us-east5 콜럼버스
us-south1 댈러스
us-west1 오리건
us-west2 로스앤젤레스
us-west3 솔트레이크시티
us-west4 라스베이거스

다음 명령어를 실행해도 지원되는 위치 목록을 확인할 수 있습니다.

gcloud privateca locations list
  1. CA 풀 및 CA를 만드는 개인에게 IAM roles/privateca.caManager를 부여합니다. MEMBER의 경우 올바른 형식은 user:userid@example.com입니다. 이 사용자가 현재 사용자라면 셸 명령어 $(gcloud auth list --filter=status:ACTIVE --format="value(account)")를 사용하여 현재 사용자 ID를 가져올 수 있습니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=MEMBER \
      --role=roles/privateca.caManager
    
  2. IAM 정책을 수정해야 하는 개인에게 CA 서비스의 role/privateca.admin 역할을 부여합니다. 여기서 MEMBER는 이 액세스 권한이 필요한 개인, 특히 privateca.auditorprivateca.certificateManager 역할을 부여하는 아래 단계를 수행하는 개인입니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=MEMBER \
      --role=roles/privateca.admin
    
  3. 루트 CA 서비스 풀을 만듭니다.

    gcloud privateca pools create ROOT_CA_POOL_NAME \
      --location ROOT_CA_POOL_LOCATION \
      --tier enterprise
    
  4. 루트 CA를 만듭니다.

    gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \
      --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \
      --key-algorithm="ec-p256-sha256" \
      --max-chain-length=1 \
      --location ROOT_CA_POOL_LOCATION
    

    이 데모 설정의 경우 변수에 다음 값을 사용합니다.

    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_NAME=pkcs2-ca
    • ROOT_CA_POOL_LOCATION=us-east1
    • ROOT_CA_ORGANIZATION="TestCorpLLC"
  5. 하위 풀과 하위 CA를 만듭니다. 기본 구성 기반 발급 모드가 계속 허용되는지 확인합니다.

    gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \
      --location SUBORDINATE_CA_POOL_LOCATION \
      --tier devops
    
    gcloud privateca subordinates create SUBORDINATE_CA_NAME \
      --pool SUBORDINATE_CA_POOL_NAME \
      --location SUBORDINATE_CA_POOL_LOCATION \
      --issuer-pool ROOT_CA_POOL_NAME \
      --issuer-location ROOT_CA_POOL_LOCATION \
      --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \
      --key-algorithm "ec-p256-sha256" \
      --use-preset-profile subordinate_mtls_pathlen_0
    

    이 데모 설정의 경우 변수에 다음 값을 사용합니다.

    • SUBORDINATE_CA_POOL_NAME="td-ca-pool"
    • SUBORDINATE_CA_POOL_LOCATION=us-east1
    • SUBORDINATE_CA_NAME="td-ca"
    • SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_POOL_LOCATION=us-east1
  6. GKE 서비스 계정에서 액세스할 수 있도록 루트 CA 풀에 IAM privateca.auditor 역할을 부여합니다.

    gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \
     --location ROOT_CA_POOL_LOCATION \
     --role roles/privateca.auditor \
     --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
    
  7. GKE 서비스 계정에서 액세스할 수 있도록 하위 CA 풀에 IAM privateca.certificateManager 역할을 부여합니다.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \
      --location SUBORDINATE_CA_POOL_LOCATION \
      --role roles/privateca.certificateManager \
      --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
    
  8. 클러스터에 메시 인증서를 발급하는 방법을 알리도록 다음 WorkloadCertificateConfig YAML 구성을 저장합니다.

    apiVersion: security.cloud.google.com/v1
    kind: WorkloadCertificateConfig
    metadata:
      name: default
    spec:
      # Required. The CA service that issues your certificates.
      certificateAuthorityConfig:
        certificateAuthorityServiceConfig:
          endpointURI: ISSUING_CA_POOL_URI
    
      # Required. The key algorithm to use. Choice of RSA or ECDSA.
      #
      # To maximize compatibility with various TLS stacks, your workloads
      # should use keys of the same family as your root and subordinate CAs.
      #
      # To use RSA, specify configuration such as:
      #   keyAlgorithm:
      #     rsa:
      #       modulusSize: 4096
      #
      # Currently, the only supported ECDSA curves are "P256" and "P384", and the only
      # supported RSA modulus sizes are 2048, 3072 and 4096.
      keyAlgorithm:
        rsa:
          modulusSize: 4096
    
      # Optional. Validity duration of issued certificates, in seconds.
      #
      # Defaults to 86400 (1 day) if not specified.
      validityDurationSeconds: 86400
    
      # Optional. Try to start rotating the certificate once this
      # percentage of validityDurationSeconds is remaining.
      #
      # Defaults to 50 if not specified.
      rotationWindowPercentage: 50
    
    

    다음을 바꿉니다.

    • 클러스터가 실행되는 프로젝트의 프로젝트 ID입니다.
      PROJECT_ID
    • 메시 인증서를 발급하는 CA의 정규화된 URI(ISSUING_CA_POOL_URI)입니다. 하위 CA(권장)이거나 루트 CA일 수 있습니다. 형식은 다음과 같습니다.
      //privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
  9. 발급된 인증서를 신뢰하는 방법을 클러스터에 지정하기 위해 다음 TrustConfig YAML 구성을 저장합니다.

    apiVersion: security.cloud.google.com/v1
    kind: TrustConfig
    metadata:
      name: default
    spec:
      # You must include a trustStores entry for the trust domain that
      # your cluster is enrolled in.
      trustStores:
      - trustDomain: PROJECT_ID.svc.id.goog
        # Trust identities in this trustDomain if they appear in a certificate
        # that chains up to this root CA.
        trustAnchors:
        - certificateAuthorityServiceURI: ROOT_CA_POOL_URI
    

    다음을 바꿉니다.

    • 클러스터가 실행되는 프로젝트의 프로젝트 ID입니다.
      PROJECT_ID
    • 루트 CA 풀의 정규화된 URI(ROOT_CA_POOL_URI)입니다. 형식은 다음과 같습니다.
      //privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME
  10. 클러스터에 구성을 적용합니다.

    kubectl apply -f WorkloadCertificateConfig.yaml
    kubectl apply -f TrustConfig.yaml
    

NEG로 프록시리스 gRPC 서비스 만들기

PSM 보안을 위해 xDS를 사용하여 Cloud Service Mesh에서 보안 구성을 가져올 수 있는 프록시리스 gRPC 서버가 필요합니다. 이 단계는 PSM 부하 분산 설정 가이드의 NEG로 GKE 서비스 구성과 비슷하지만 java-example-hostname 이미지 대신 grpc-java 저장소의 xDS 예시에 있는 xDS가 사용 설정된 helloworld 서버를 사용합니다.

openjdk:8-jdk 이미지로 빌드된 컨테이너에서 이 서버를 빌드하고 실행합니다. NEG 이름을 지정할 수 있는 이름이 지정된 NEG 기능도 사용합니다. 이렇게 하면 NEG를 조회할 필요 없이 NEG의 이름이 배포되므로 이후 단계가 간소화됩니다.

다음은 gRPC 서버 Kubernetes 사양의 전체 예시입니다. 다음에 유의하세요.

  • 사양은 gRPC 서버 포드에서 사용되는 Kubernetes 서비스 계정 example-grpc-server를 만듭니다.
  • 사양은 서비스의 cloud.google.com/neg 주석에 있는 name 필드를 사용하여 NEG 이름 example-grpc-server를 지정합니다.
  • ${PROJNUM} 변수는 프로젝트의 프로젝트 번호를 나타냅니다.
  • 사양은 initContainers 섹션을 사용해서 부트스트랩 생성기를 실행하여 프록시리스 gRPC 라이브러리에 필요한 부트스트랩 파일을 채웁니다. 이 부트스트랩 파일은 example-grpc-server라는 gRPC 서버 컨테이너의 /tmp/grpc-xds/td-grpc-bootstrap.json에 있습니다.

포드 사양에 다음 주석을 추가합니다.

 annotations:
   security.cloud.google.com/use-workload-certificates: ""

다음에 이어지는 전체 사양에서 올바른 게재위치를 확인할 수 있습니다.

생성 시 각 포드는 /var/run/secrets/workload-spiffe-credentials에서 볼륨을 가져옵니다. 이 볼륨에는 다음이 포함됩니다.

  • private_key.pem은 자동으로 생성되는 비공개 키입니다.
  • certificates.pem은 다른 포드에 클라이언트 인증서 체인으로 제시되거나 서버 인증서 체인으로 사용될 수 있는 PEM 형식의 인증서 번들입니다.
  • ca_certificates.pem은 다른 포드에서 제공하는 클라이언트 인증서 체인 또는 다른 포드에 연결할 때 수신된 서버 인증서 체인을 확인할 때 신뢰 앵커로 사용할 PEM 형식의 인증서 번들입니다.

참고로 ca_certificates.pem에는 클러스터의 워크로드 풀인 워크로드의 로컬 트러스트 도메인의 인증서가 포함됩니다.

certificates.pem의 리프 인증서에는 다음과 같은 일반 텍스트 SPIFFE ID 어설션이 포함되어 있습니다.

spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT

이 어설션의 내용은 다음과 같습니다.

  • WORKLOAD_POOL은 클러스터 워크로드 풀의 이름입니다.
  • NAMESPACE는 Kubernetes 서비스 계정의 네임스페이스입니다.
  • KUBERNETES_SERVICE_ACCOUNT는 Kubernetes 서비스 계정의 이름입니다.

다음과 같은 언어별 안내에 따라 이 예시에서 사용할 사양을 만듭니다.

자바

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 사양을 만듭니다.

    cat << EOF > example-grpc-server.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
     name: example-grpc-server
     namespace: default
     annotations:
       iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
     annotations:
       cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}'
    spec:
     ports:
     - name: helloworld
       port: 8080
       protocol: TCP
       targetPort: 50051
     selector:
       k8s-app: example-grpc-server
     type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
    spec:
     replicas: 1
     selector:
       matchLabels:
         k8s-app: example-grpc-server
     strategy: {}
     template:
       metadata:
         annotations:
            security.cloud.google.com/use-workload-certificates: ""
         labels:
           k8s-app: example-grpc-server
       spec:
         containers:
         - image: openjdk:8-jdk
           imagePullPolicy: IfNotPresent
           name: example-grpc-server
           command:
           - /bin/sleep
           - inf
           env:
           - name: GRPC_XDS_BOOTSTRAP
             value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
           ports:
           - protocol: TCP
             containerPort: 50051
           resources:
             limits:
               cpu: 800m
               memory: 512Mi
             requests:
               cpu: 100m
               memory: 512Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/grpc-xds/
         initContainers:
         - name: grpc-td-init
           image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

C++

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 사양을 만듭니다.

    cat << EOF > example-grpc-server.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
     name: example-grpc-server
     namespace: default
     annotations:
       iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
     annotations:
       cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}'
    spec:
     ports:
     - name: helloworld
       port: 8080
       protocol: TCP
       targetPort: 50051
     selector:
       k8s-app: example-grpc-server
     type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
    spec:
     replicas: 1
     selector:
       matchLabels:
         k8s-app: example-grpc-server
     strategy: {}
     template:
       metadata:
         annotations:
            security.cloud.google.com/use-workload-certificates: ""
         labels:
           k8s-app: example-grpc-server
       spec:
         containers:
         - image: phusion/baseimage:18.04-1.0.0
           imagePullPolicy: IfNotPresent
           name: example-grpc-server
           command:
           - /bin/sleep
           - inf
           env:
           - name: GRPC_XDS_BOOTSTRAP
             value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
           ports:
           - protocol: TCP
             containerPort: 50051
           resources:
             limits:
               cpu: 8
               memory: 8Gi
             requests:
               cpu: 300m
               memory: 512Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/grpc-xds/
         initContainers:
         - name: grpc-td-init
           image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

Python

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 사양을 만듭니다.

    cat << EOF > example-grpc-server.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
     name: example-grpc-server
     namespace: default
     annotations:
       iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
     annotations:
       cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}'
    spec:
     ports:
     - name: helloworld
       port: 8080
       protocol: TCP
       targetPort: 50051
     selector:
       k8s-app: example-grpc-server
     type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
    spec:
     replicas: 1
     selector:
       matchLabels:
         k8s-app: example-grpc-server
     strategy: {}
     template:
       metadata:
         annotations:
            security.cloud.google.com/use-workload-certificates: ""
         labels:
           k8s-app: example-grpc-server
       spec:
         containers:
         - image: phusion/baseimage:18.04-1.0.0
           imagePullPolicy: IfNotPresent
           name: example-grpc-server
           command:
           - /bin/sleep
           - inf
           env:
           - name: GRPC_XDS_BOOTSTRAP
             value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
           ports:
           - protocol: TCP
             containerPort: 50051
           resources:
             limits:
               cpu: 8
               memory: 8Gi
             requests:
               cpu: 300m
               memory: 512Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/grpc-xds/
         initContainers:
         - name: grpc-td-init
           image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

Go

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 사양을 만듭니다.

    cat << EOF > example-grpc-server.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
     name: example-grpc-server
     namespace: default
     annotations:
       iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
     annotations:
       cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-grpc-server"}}}'
    spec:
     ports:
     - name: helloworld
       port: 8080
       protocol: TCP
       targetPort: 50051
     selector:
       k8s-app: example-grpc-server
     type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: example-grpc-server
     namespace: default
     labels:
       k8s-app: example-grpc-server
    spec:
     replicas: 1
     selector:
       matchLabels:
         k8s-app: example-grpc-server
     strategy: {}
     template:
       metadata:
         annotations:
            security.cloud.google.com/use-workload-certificates: ""
         labels:
           k8s-app: example-grpc-server
       spec:
         containers:
         - image: golang:1.16-alpine
           imagePullPolicy: IfNotPresent
           name: example-grpc-server
           command:
           - /bin/sleep
           - inf
           env:
           - name: GRPC_XDS_BOOTSTRAP
             value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
           ports:
           - protocol: TCP
             containerPort: 50051
           resources:
             limits:
               cpu: 8
               memory: 8Gi
             requests:
               cpu: 300m
               memory: 512Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/grpc-xds/
         initContainers:
         - name: grpc-td-init
           image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
           imagePullPolicy: Always
           args:
           - --config-mesh-experimental
           - "grpc-mesh"
           - --output
           - "/tmp/bootstrap/td-grpc-bootstrap.json"
           - --node-metadata=app=helloworld
           resources:
             limits:
               cpu: 100m
               memory: 100Mi
             requests:
               cpu: 10m
               memory: 100Mi
           volumeMounts:
           - name: grpc-td-conf
             mountPath: /tmp/bootstrap/
         serviceAccountName: example-grpc-server
         volumes:
         - name: grpc-td-conf
           emptyDir:
             medium: Memory
    EOF
    

    다음과 같이 프로세스를 완료합니다.

  1. 사양을 적용합니다.

    kubectl apply -f example-grpc-server.yaml
    
  2. 서비스 계정에 필요한 역할을 부여합니다.

    gcloud iam service-accounts add-iam-policy-binding \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-server]" \
      ${PROJNUM}-compute@developer.gserviceaccount.com
    
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
      --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-server]" \
      --role roles/trafficdirector.client
    
  3. 다음 명령어를 실행하여 서비스와 포드가 올바르게 생성되었는지 확인합니다.

    kubectl get deploy/example-grpc-server
    kubectl get svc/example-grpc-server
    
  4. NEG 이름이 올바른지 확인합니다.

    gcloud compute network-endpoint-groups list \
        --filter "name=example-grpc-server" --format "value(name)"
    

    명령어에서 NEG 이름 example-grpc-server를 반환해야 합니다.

Google Cloud 부하 분산 구성요소로 Cloud Service Mesh 구성

이 섹션의 단계는 부하 분산 구성요소로 Cloud Service Mesh 구성의 단계와 비슷하지만 다음 섹션의 설명대로 몇 가지 변경사항이 있습니다.

상태 점검, 방화벽 규칙 및 백엔드 서비스 만들기

gRPC 서버가 mTLS를 사용하도록 구성된 경우에는 상태 점검 클라이언트에서 유효한 클라이언트 인증서를 서버에 제공할 수 없으므로 gRPC 상태 점검이 작동하지 않습니다. 두 가지 방법 중 하나로 이를 해결할 수 있습니다.

첫 번째 방식에서는 서버가 상태 확인 포트로 지정된 추가 제공 포트를 만들도록 합니다. 이는 해당 포트에 대한 일반 텍스트나 TLS로서 특수 상태 점검 서비스에 연결됩니다.

xDS helloworld 예시 서버PORT_NUMBER + 1을 일반 텍스트 상태 점검 포트로 사용합니다. 이 예시에서는 50051이 gRPC 애플리케이션 서버 포트이므로 상태 확인 포트로 50052를 사용합니다.

두 번째 방법에서는 애플리케이션 제공 포트에 대한 TCP 연결만 확인하도록 상태 확인을 구성합니다. 이는 연결만 확인하며 TLS 핸드셰이크가 실패할 때 서버에 불필요한 트래픽을 생성합니다. 따라서 첫 번째 방법을 사용하는 것이 좋습니다.

  1. 상태 확인을 만듭니다. 서버를 만들고 시작할 때까지 상태 점검은 시작되지 않습니다.

    • 권장하는 방법인 상태 확인을 위해 지정된 제공 포트를 만드는 경우 다음 명령어를 사용합니다.

      gcloud compute health-checks create grpc grpc-gke-helloworld-hc \
       --enable-logging --port 50052
      
    • 권장하지 않는 TCP 상태 점검을 만드는 경우에는 다음 명령어를 사용합니다.

      gcloud compute health-checks create tcp grpc-gke-helloworld-hc \
      --use-serving-port
      
  2. 방화벽을 만듭니다. --target-tags 값이 GKE 클러스터 만들기 또는 업데이트 섹션에서 --tags에 제공한 값과 일치하는지 확인합니다.

    gcloud compute firewall-rules create grpc-gke-allow-health-checks \
      --network default --action allow --direction INGRESS \
      --source-ranges 35.191.0.0/16,130.211.0.0/22 \
      --target-tags allow-health-checks \
      --rules tcp:50051-50052
    
  3. 백엔드 서비스를 만듭니다.

    gcloud compute backend-services create grpc-gke-helloworld-service \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --protocol=GRPC \
       --health-checks grpc-gke-helloworld-hc
    
  4. 백엔드 서비스에 NEG를 연결합니다.

    gcloud compute backend-services add-backend grpc-gke-helloworld-service \
       --global \
       --network-endpoint-group example-grpc-server \
       --network-endpoint-group-zone ${ZONE} \
       --balancing-mode RATE \
       --max-rate-per-endpoint 5
    

MeshGRPCRoute 리소스 만들기

이는 프록시리스 gRPC 서비스 설정MeshGRPCRoute 리소스를 설정하는 방법과 비슷합니다.

  1. Mesh 사양을 만들고 mesh.yaml 파일에 저장합니다.

    name: grpc-mesh
    
  2. 사양에서 Mesh 리소스를 가져옵니다.

    gcloud network-services meshes import grpc-mesh \
      --source=mesh.yaml \
      --location=global
    
  3. GRPCRoute 사양을 만들고 grpc_route.yaml 파일에 저장합니다.

    name: helloworld-grpc-route
    hostnames:
    - helloworld-gke:8000
    meshes:
    - projects/PROJECT_NUMBER/locations/global/meshes/grpc-mesh
    rules:
    - action:
        destinations:
        - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/grpc-gke-helloworld-service
    
  4. grpc_route.yaml 사양에서 GRPCRoute 리소스를 가져옵니다.

    gcloud network-services grpc-routes import helloworld-grpc-route \
      --source=grpc_route.yaml \
      --location=global
    

프록시리스 gRPC 보안으로 Cloud Service Mesh 구성

이 예시에서는 클라이언트 및 서버 측에서 mTLS를 구성하는 방법을 보여줍니다.

정책 참조 형식

서버 TLS 정책과 클라이언트 TLS 정책을 참조하는 데 필요한 형식은 다음과 같습니다.

projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies]/[server-tls-policy|client-mtls-policy]

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

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

서버 측에서 mTLS 구성

먼저 서버 TLS 정책을 만듭니다. 이 정책은 gRPC 서버 측에 serverCertificate의 일부인 ID 인증서에 대해 google_cloud_private_spiffe 이름으로 식별된 certificateProvicerInstance 플러그인 구성을 사용하도록 요청합니다. mtlsPolicy 섹션은 mTLS 보안을 나타내고 루트(유효성 검사) 인증서 사양인 clientValidationCa의 플러그인 구성과 동일한 google_cloud_private_spiffe를 사용합니다.

그런 다음 엔드포인트 정책을 만듭니다. 예를 들어 백엔드 gRPC 서버(포트 50051을 메타데이터 라벨 없이 사용하거나 사용하지 않음)가 server-mtls-policy라는 연결된 서버 TLS 정책을 수신하도록 지정합니다. MATCH_ALL 또는 지원되는 값을 사용하여 메타데이터 라벨을 지정합니다. 지원되는 메타데이터 라벨은 NetworkServicesEndpointPolicy 문서endpointMatcher.metadataLabelMatcher.metadataLabelMatchCriteria 라벨에서 찾을 수 있습니다. 이미 정의한 정책을 사용하여 엔드포인트 정책 리소스의 값이 포함된 임시 파일 ep-mtls-psms.yaml로 엔드포인트 정책을 만듭니다.

  1. 서버 TLS 정책 리소스 값을 사용하여 현재 디렉터리에 임시 파일 server-mtls-policy.yaml을 만듭니다.

    name: "projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy"
    serverCertificate:
      certificateProviderInstance:
        pluginInstance: google_cloud_private_spiffe
    mtlsPolicy:
      clientValidationCa:
      - certificateProviderInstance:
          pluginInstance: google_cloud_private_spiffe
    
  2. 임시 파일 server-mtls-policy.yaml을 가져와 server-mtls-policy라는 서버 TLS 정책 리소스를 만듭니다.

    gcloud network-security server-tls-policies import server-mtls-policy \
      --source=server-mtls-policy.yaml --location=global
    
  3. 임시 파일 ep-mtls-psms.yaml을 생성하여 엔드포인트 정책을 만듭니다.

    name: "ep-mtls-psms"
    type: "GRPC_SERVER"
    serverTlsPolicy: "projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy"
    trafficPortSelector:
      ports:
      - "50051"
    endpointMatcher:
      metadataLabelMatcher:
        metadataLabelMatchCriteria: "MATCH_ALL"
        metadataLabels:
        - labelName: app
          labelValue: helloworld
    
  4. ep-mtls-psms.yaml 파일을 가져와 엔드포인트 정책 리소스를 만듭니다.

    gcloud beta network-services endpoint-policies import ep-mtls-psms \
      --source=ep-mtls-psms.yaml --location=global
    

클라이언트 측에서 mTLS 구성

클라이언트 측 보안 정책은 백엔드 서비스에 연결됩니다. 클라이언트가 백엔드 서비스를 통해 백엔드(gRPC 서버)에 액세스하면 연결된 클라이언트 측 보안 정책이 클라이언트로 전송됩니다.

  1. 현재 디렉터리에 있는 client-mtls-policy.yaml이라는 임시 파일에 클라이언트 TLS 정책 리소스 콘텐츠를 만듭니다.

    name: "client-mtls-policy"
    clientCertificate:
      certificateProviderInstance:
        pluginInstance: google_cloud_private_spiffe
    serverValidationCa:
    - certificateProviderInstance:
        pluginInstance: google_cloud_private_spiffe
    
  2. 임시 파일 client-mtls-policy.yaml을 가져와 client-mtls-policy라는 클라이언트 TLS 정책 리소스를 만듭니다.

    gcloud network-security client-tls-policies import client-mtls-policy \
      --source=client-mtls-policy.yaml --location=global
    
  3. 이 정책을 참조하는 임시 파일에 스니펫을 만들고 다음 예시와 같이 SecuritySettings 메시지의 subjectAltNames에 대한 세부정보를 추가합니다. ${PROJECT_ID}를 앞에서 설명한 ${PROJECT_ID} 환경 변수 값인 프로젝트 ID 값으로 바꿉니다. subjectAltNamesexample-grpc-server는 배포 사양의 gRPC 서버 포드에 사용되는 Kubernetes 서비스 계정 이름입니다.

    if [ -z "$PROJECT_ID" ] ; then echo Please make sure PROJECT_ID is set. ; fi
    cat << EOF > client-security-settings.yaml
    securitySettings:
      clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client-mtls-policy
      subjectAltNames:
        - "spiffe://${PROJECT_ID}.svc.id.goog/ns/default/sa/example-grpc-server"
    EOF
    
  4. 이미 만든 백엔드 서비스에 securitySettings 메시지를 추가합니다. 이 단계는 현재 백엔드 서비스 콘텐츠를 내보내고, 클라이언트 securitySetting 메시지를 추가하며, 새 콘텐츠를 다시 가져와서 백엔드 서비스를 업데이트합니다.

    gcloud compute backend-services export grpc-gke-helloworld-service --global \
      --destination=/tmp/grpc-gke-helloworld-service.yaml
    
    cat /tmp/grpc-gke-helloworld-service.yaml client-security-settings.yaml \
      >/tmp/grpc-gke-helloworld-service1.yaml
    
    gcloud compute backend-services import grpc-gke-helloworld-service --global \
      --source=/tmp/grpc-gke-helloworld-service1.yaml -q
    

구성 확인

이제 서버 측 및 클라이언트 측 보안을 포함하여 Cloud Service Mesh 구성이 완료되었습니다. 다음으로 서버 및 클라이언트 워크로드를 준비하고 실행해야 합니다. 그러면 예제가 완료됩니다.

프록시리스 gRPC 클라이언트 만들기

이 단계는 이전 단계인 프록시리스 gRPC 서비스 만들기와 비슷합니다. grpc-java 저장소의 xDS 예시 디렉터리에서 xDS가 사용 설정된 helloworld 클라이언트를 사용합니다. openjdk:8-jdk 이미지로 빌드된 컨테이너에서 클라이언트를 빌드하고 실행합니다. gRPC 클라이언트 Kubernetes 사양에서는 다음을 수행합니다.

  • gRPC 클라이언트 포드에서 사용하는 Kubernetes 서비스 계정 example-grpc-client를 만듭니다.
  • ${PROJNUM}은 프로젝트의 프로젝트 번호를 나타내며 실제 번호로 바꿔야 합니다.

포드 사양에 다음 주석을 추가합니다.

  annotations:
    security.cloud.google.com/use-workload-certificates: ""

생성 시 각 포드는 /var/run/secrets/workload-spiffe-credentials에서 볼륨을 가져옵니다. 이 볼륨에는 다음이 포함됩니다.

  • private_key.pem은 자동으로 생성되는 비공개 키입니다.
  • certificates.pem은 다른 포드에 클라이언트 인증서 체인으로 제시되거나 서버 인증서 체인으로 사용될 수 있는 PEM 형식의 인증서 번들입니다.
  • ca_certificates.pem은 다른 포드에서 제공하는 클라이언트 인증서 체인 또는 다른 포드에 연결할 때 수신된 서버 인증서 체인을 확인할 때 신뢰 앵커로 사용할 PEM 형식의 인증서 번들입니다.

ca_certificates.pem에는 클러스터의 워크로드 풀인 워크로드의 로컬 트러스트 도메인에 대한 루트 인증서가 포함됩니다.

certificates.pem의 리프 인증서에는 다음과 같은 일반 텍스트 SPIFFE ID 어설션이 포함되어 있습니다.

spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT

이 어설션의 내용은 다음과 같습니다.

  • WORKLOAD_POOL은 클러스터 워크로드 풀의 이름입니다.
  • NAMESPACE는 Kubernetes 서비스 계정의 이름입니다.
  • KUBERNETES_SERVICE_ACCOUNT는 Kubernetes 서비스 계정의 네임스페이스입니다.

다음과 같은 언어별 안내에 따라 이 예시에서 사용할 사양을 만듭니다.

자바

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 다음 사양을 만듭니다.

    cat << EOF > example-grpc-client.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: example-grpc-client
      namespace: default
      annotations:
        iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: example-grpc-client
      namespace: default
      labels:
        k8s-app: example-grpc-client
    spec:
      replicas: 1
      selector:
        matchLabels:
          k8s-app: example-grpc-client
      strategy: {}
      template:
        metadata:
          annotations:
            security.cloud.google.com/use-workload-certificates: ""
          labels:
            k8s-app: example-grpc-client
        spec:
          containers:
          - image: openjdk:8-jdk
            imagePullPolicy: IfNotPresent
            name: example-grpc-client
            command:
            - /bin/sleep
            - inf
            env:
            - name: GRPC_XDS_BOOTSTRAP
              value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 800m
                memory: 512Mi
              requests:
                cpu: 100m
                memory: 512Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/grpc-xds/
          initContainers:
          - name: grpc-td-init
            image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - --config-mesh-experimental
            - "grpc-mesh"
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

C++

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 다음 사양을 만듭니다.

    cat << EOF > example-grpc-client.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: example-grpc-client
      namespace: default
      annotations:
        iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: example-grpc-client
      namespace: default
      labels:
        k8s-app: example-grpc-client
    spec:
      replicas: 1
      selector:
        matchLabels:
          k8s-app: example-grpc-client
      strategy: {}
      template:
        metadata:
          annotations:
            security.cloud.google.com/use-workload-certificates: ""
          labels:
            k8s-app: example-grpc-client
        spec:
          containers:
          - image: phusion/baseimage:18.04-1.0.0
            imagePullPolicy: IfNotPresent
            name: example-grpc-client
            command:
            - /bin/sleep
            - inf
            env:
            - name: GRPC_XDS_BOOTSTRAP
              value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 8
                memory: 8Gi
              requests:
                cpu: 300m
                memory: 512Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/grpc-xds/
          initContainers:
          - name: grpc-td-init
            image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

Python

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 다음 사양을 만듭니다.

    cat << EOF > example-grpc-client.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: example-grpc-client
      namespace: default
      annotations:
        iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: example-grpc-client
      namespace: default
      labels:
        k8s-app: example-grpc-client
    spec:
      replicas: 1
      selector:
        matchLabels:
          k8s-app: example-grpc-client
      strategy: {}
      template:
        metadata:
          annotations:
            security.cloud.google.com/use-workload-certificates: ""
          labels:
            k8s-app: example-grpc-client
        spec:
          containers:
          - image: phusion/baseimage:18.04-1.0.0
            imagePullPolicy: IfNotPresent
            name: example-grpc-client
            command:
            - /bin/sleep
            - inf
            env:
            - name: GRPC_XDS_BOOTSTRAP
              value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 8
                memory: 8Gi
              requests:
                cpu: 300m
                memory: 512Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/grpc-xds/
          initContainers:
          - name: grpc-td-init
            image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

Go

  1. 다음 명령어를 실행하여 프로젝트 번호가 올바르게 설정되었는지 확인합니다.

    if [ -z "$PROJNUM" ] ; then export PROJNUM=$(gcloud projects describe $(gcloud info --format='value(config.project)') --format="value(projectNumber)") ; fi ; echo $PROJNUM
    
  2. 다음 사양을 만듭니다.

    cat << EOF > example-grpc-client.yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: example-grpc-client
      namespace: default
      annotations:
        iam.gke.io/gcp-service-account: ${PROJNUM}-compute@developer.gserviceaccount.com
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: example-grpc-client
      namespace: default
      labels:
        k8s-app: example-grpc-client
    spec:
      replicas: 1
      selector:
        matchLabels:
          k8s-app: example-grpc-client
      strategy: {}
      template:
        metadata:
          annotations:
            security.cloud.google.com/use-workload-certificates: ""
          labels:
            k8s-app: example-grpc-client
        spec:
          containers:
          - image: golang:1.16-alpine
            imagePullPolicy: IfNotPresent
            name: example-grpc-client
            command:
            - /bin/sleep
            - inf
            env:
            - name: GRPC_XDS_BOOTSTRAP
              value: "/tmp/grpc-xds/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 8
                memory: 8Gi
              requests:
                cpu: 300m
                memory: 512Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/grpc-xds/
          initContainers:
          - name: grpc-td-init
            image: gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0
            imagePullPolicy: Always
            args:
            - --config-mesh-experimental
            - "grpc-mesh"
            - --output
            - "/tmp/bootstrap/td-grpc-bootstrap.json"
            resources:
              limits:
                cpu: 100m
                memory: 100Mi
              requests:
                cpu: 10m
                memory: 100Mi
            volumeMounts:
            - name: grpc-td-conf
              mountPath: /tmp/bootstrap/
          serviceAccountName: example-grpc-client
          volumes:
          - name: grpc-td-conf
            emptyDir:
              medium: Memory
    EOF
    

다음과 같이 프로세스를 완료합니다.

  1. 사양을 적용합니다.

    kubectl apply -f example-grpc-client.yaml
    
  2. 서비스 계정에 필요한 역할을 부여합니다.

    gcloud iam service-accounts add-iam-policy-binding \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-client]" \
      ${PROJNUM}-compute@developer.gserviceaccount.com
    
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
      --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-client]" \
      --role roles/trafficdirector.client
    
  3. 클라이언트 포드가 실행 중인지 확인합니다.

    kubectl get pods
    

    이 명령어는 다음과 비슷한 텍스트를 반환합니다.

    NAMESPACE   NAME                                    READY   STATUS    RESTARTS   AGE
    default     example-grpc-client-7c969bb997-9fzjv    1/1     Running   0          104s
    [..skip..]
    

서버 실행

이전에 만든 서버 포드에서 xDS가 사용 설정된 helloworld 서버를 빌드하고 실행합니다.

자바

  1. example-grpc-server 서비스를 위해 만든 포드 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-server
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. 서버 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
    
  3. 셸에서 /tmp/grpc-xds/td-grpc-bootstrap.json의 부트스트랩 파일이 부트스트랩 파일 섹션에서 설명한 스키마와 일치하는지 확인합니다.

  4. gRPC 자바 버전 1.42.1을 다운로드하고 xds-hello-world 서버 애플리케이션을 빌드합니다.

    curl -L https://github.com/grpc/grpc-java/archive/v1.42.1.tar.gz | tar -xz
    
    cd grpc-java-1.42.1/examples/example-xds
    
    ../gradlew --no-daemon installDist
    
  5. --xds-creds 플래그로 서버를 실행하여 50051을 수신 포트로, xds-server를 서버 식별 이름으로 사용해 xDS가 사용 설정된 보안을 나타냅니다.

    ./build/install/example-xds/bin/xds-hello-world-server --xds-creds 50051 xds-server
    
  6. 서버에서 Cloud Service Mesh에서 필요한 구성을 가져오면 다음과 같은 출력이 표시됩니다.

    Listening on port 50051
    plain text health service listening on port 50052
    

C++

  1. example-grpc-server 서비스를 위해 만든 포드 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-server
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. 서버 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
    
  3. 셸에서 /tmp/grpc-xds/td-grpc-bootstrap.json의 부트스트랩 파일이 부트스트랩 파일 섹션에서 설명한 스키마와 일치하는지 확인합니다.

  4. gRPC C++를 다운로드하고 xds-hello-world 서버 애플리케이션을 빌드합니다.

    apt-get update -y && \
            apt-get install -y \
                build-essential \
                clang \
                python3 \
                python3-dev
    
    curl -L https://github.com/grpc/grpc/archive/master.tar.gz | tar -xz
    
    cd grpc-master
    
    tools/bazel build examples/cpp/helloworld:xds_greeter_server
    
  5. 50051을 수신 포트로, xds_greeter_server를 서버 식별 이름으로 사용하여 서버를 실행합니다.

    bazel-bin/examples/cpp/helloworld/xds_greeter_server --port=50051 --maintenance_port=50052 --secure
    

    사용자 인증 정보 없이 서버를 실행하려면 다음을 지정하면 됩니다.

    bazel-bin/examples/cpp/helloworld/xds_greeter_server --nosecure
    
  6. 서버에서 Cloud Service Mesh에서 필요한 구성을 가져오면 다음과 같은 출력이 표시됩니다.

    Listening on port 50051
    plain text health service listening on port 50052
    

Python

  1. example-grpc-server 서비스를 위해 만든 포드 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-server
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. 서버 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/bash
    
  3. 셸에서 /tmp/grpc-xds/td-grpc-bootstrap.json의 부트스트랩 파일이 부트스트랩 파일 섹션에서 설명한 스키마와 일치하는지 확인합니다.

  4. gRPC Python 버전 1.41.0을 다운로드하고 예시 애플리케이션을 빌드합니다.

    apt-get update -y
    
    apt-get install -y python3 python3-pip
    
    curl -L https://github.com/grpc/grpc/archive/v1.41.x.tar.gz | tar -xz
    
    cd grpc-1.41.x/examples/python/xds/
    
    python3 -m virtualenv venv
    
    source venv/bin/activate
    
    python3 -m pip install -r requirements.txt
    

  5. --xds-creds 플래그로 서버를 실행하여 50051을 수신 포트로 사용해 xDS가 사용 설정된 보안을 나타냅니다.

    python3 server.py 50051 --xds-creds
    
  6. 서버에서 Cloud Service Mesh에서 필요한 구성을 가져오면 다음과 같은 출력이 표시됩니다.

    2021-05-06 16:10:34,042: INFO     Running with xDS Server credentials
    2021-05-06 16:10:34,043: INFO     Greeter server listening on port 50051
    2021-05-06 16:10:34,046: INFO     Maintenance server listening on port 50052
    

Go

  1. example-grpc-server 서비스를 위해 만든 포드 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-server
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-server-77548868d-l9hmf     1/1    Running   0     105s
    
  2. 서버 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-server-77548868d-l9hmf -- /bin/sh
    
  3. 셸에서 /tmp/grpc-xds/td-grpc-bootstrap.json의 부트스트랩 파일이 부트스트랩 파일 섹션에서 설명한 스키마와 일치하는지 확인합니다.

  4. gRPC Go 버전 1.41.0을 다운로드하고 xds-hello-world 서버 애플리케이션이 있는 디렉터리로 이동합니다.

    apk add curl
    
    curl -L https://github.com/grpc/grpc-go/archive/v1.42.0.tar.gz | tar -xz
    
    cd grpc-go-1.42.0/examples/features/xds/server
    
    
  5. --xds_creds 플래그로 서버를 빌드하고 실행하여 50051를 수신 포트로 사용해 xDS가 사용 설정된 보안을 나타냅니다.

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -port 50051
    
  6. 서버에서 Cloud Service Mesh에서 필요한 구성을 가져오면 다음과 같은 출력이 표시됩니다.

    Using xDS credentials...
    Serving GreeterService on 0.0.0.0:50051 and HealthService on 0.0.0.0:50052
    

상태 점검 프로세스에서 서버가 시작된 후 서비스가 정상임을 표시하는 데 3~5분이 소요됩니다.

클라이언트 실행 및 구성 확인

이전에 만든 클라이언트 포드에서 xDS가 사용 설정된 helloworld 클라이언트를 빌드하고 실행합니다.

자바

  1. 클라이언트 포드의 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-client
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. 클라이언트 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  3. 명령어 셸에서 gRPC 자바 버전 1.42.1을 다운로드하고 xds-hello-world 클라이언트 애플리케이션을 빌드합니다.

    curl -L https://github.com/grpc/grpc-java/archive/v1.42.1.tar.gz | tar -xz
    
    cd grpc-java-1.42.1/examples/example-xds
    
    ../gradlew --no-daemon installDist
    
  4. --xds-creds 플래그로 클라이언트를 실행하여 xDS가 사용 설정된 보안, 클라이언트 이름, 대상 연결 문자열을 표시합니다.

    ./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \
          xds:///helloworld-gke:8000
    

    다음과 비슷한 출력이 표시됩니다.

    Greeting: Hello xds-client, from xds-server
    

C++

  1. 클라이언트 포드의 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-client
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. 클라이언트 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  3. 셸 안에 들어가면 gRPC C++를 다운로드하고 xds-hello-world 클라이언트 애플리케이션을 빌드합니다.

    apt-get update -y && \
            apt-get install -y \
                build-essential \
                clang \
                python3 \
                python3-dev
    
    curl -L https://github.com/grpc/grpc/archive/master.tar.gz | tar -xz
    
    cd grpc-master
    
    tools/bazel build examples/cpp/helloworld:xds_greeter_client
    
  4. --xds-creds 플래그로 클라이언트를 실행하여 xDS가 사용 설정된 보안, 클라이언트 이름, 대상 연결 문자열을 표시합니다.

    bazel-bin/examples/cpp/helloworld/xds_greeter_client --target=xds:///helloworld-gke:8000
    

    사용자 인증 정보 없이 클라이언트를 실행하려면 다음을 사용합니다.

    bazel-bin/examples/cpp/helloworld/xds_greeter_client --target=xds:///helloworld-gke:8000 --nosecure
    

    다음과 비슷한 출력이 표시됩니다.

    Greeter received: Hello world
    

Python

  1. 클라이언트 포드의 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-client
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. 클라이언트 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  3. 셸 안에 들어가면 gRPC Python 버전 1.41.0을 다운로드하고 예시 클라이언트 애플리케이션을 빌드합니다.

    apt-get update -y
    apt-get install -y python3 python3-pip
    python3 -m pip install virtualenv
    curl -L https://github.com/grpc/grpc/archive/v1.41.x.tar.gz | tar -xz
    cd grpc-1.41.x/examples/python/xds/
    python3 -m virtualenv venv
    source venv/bin/activate
    python3 -m pip install -r requirements.txt
    
  4. --xds-creds 플래그로 클라이언트를 실행하여 xDS가 사용 설정된 보안, 클라이언트 이름, 대상 연결 문자열을 표시합니다.

    python3 client.py xds:///helloworld-gke:8000 --xds-creds
    

    다음과 비슷한 출력이 표시됩니다.

    Greeter client received: Hello you from example-host!
    

Go

  1. 클라이언트 포드의 이름을 가져옵니다.

    kubectl get pods | grep example-grpc-client
    

    다음과 같은 피드백이 표시됩니다.

    default    example-grpc-client-7c969bb997-9fzjv     1/1    Running   0     105s
    
  2. 클라이언트 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/sh
    
  3. 셸 안에 들어가면 gRPC Go 버전 1.42.0을 다운로드하고 xds-hello-world 클라이언트 애플리케이션이 있는 디렉터리로 이동합니다.

    apk add curl
    
    curl -L https://github.com/grpc/grpc-go/archive/v1.42.0.tar.gz | tar -xz
    
    cd grpc-go-1.42.0/examples/features/xds/client
    
  4. --xds_creds 플래그를 사용하여 클라이언트를 빌드하고 실행하여 xDS가 사용 설정된 보안, 클라이언트 이름, 대상 연결 문자열을 표시합니다.

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -name xds-client \
      -target xds:///helloworld-gke:8000
    

    다음과 비슷한 출력이 표시됩니다.

    Greeting: Hello xds-client, from example-grpc-server-77548868d-l9hmf
    

승인 정책을 사용한 서비스 수준 액세스 구성

gRFC A41 지원은 승인 정책 지원에 필요합니다. github에서 필요한 언어 버전을 찾을 수 있습니다.

안내에 따라 승인 정책을 사용하여 서비스 수준 액세스를 구성합니다. 승인 정책을 만들기 전에 승인을 사용하여 액세스 제한의 주의 사항을 읽어보세요.

구성을 더 쉽게 확인하기 위해서는 helloworld-gke 서비스 참조를 위해 클라이언트가 사용할 수 있는 추가 호스트 이름을 만듭니다.

  1. 이전에 grpc_route.yaml에 저장된 GRPCRoute 사양을 업데이트합니다.

    name: helloworld-grpc-route
    hostnames:
    - helloworld-gke:8000
    - helloworld-gke-noaccess:8000
    meshes:
    - projects/PROJECT_NUMBER/locations/global/meshes/grpc-mesh
    rules:
    - action:
        destinations:
        - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/grpc-gke-helloworld-service
    
  2. grpc_route.yaml 사양에서 GRPCRoute 리소스를 다시 가져옵니다.

    gcloud network-services grpc-routes import helloworld-grpc-route \
      --source=grpc_route.yaml \
      --location=global
    

다음 안내에서는 호스트 이름이 helloworld-gke:8000이고 포트가 50051example-grpc-client 계정에서 전송된 요청을 허용하는 승인 정책을 만듭니다.

gcloud

  1. helloworld-gke-authz-policy.yaml 파일을 생성하여 승인 정책을 만듭니다.

    action: ALLOW
    name: helloworld-gke-authz-policy
    rules:
    - sources:
      - principals:
        - spiffe://PROJECT_ID.svc.id.goog/ns/default/sa/example-grpc-client
      destinations:
      - hosts:
        - helloworld-gke:8000
        ports:
        - 50051
    
  2. 정책을 가져옵니다.

    gcloud network-security authorization-policies import \
      helloworld-gke-authz-policy \
      --source=helloworld-gke-authz-policy.yaml \
      --location=global
    
  3. ep-mtls-psms.yaml 파일에 다음을 추가하여 엔드포인트 정책이 새 승인 정책을 참조하도록 업데이트합니다.

    authorizationPolicy: projects/${PROJECT_ID}/locations/global/authorizationPolicies/helloworld-gke-authz-policy
    

    이제 엔드포인트 정책은 gRPC 부트스트랩 파일에 app:helloworld 라벨을 포함하는 포드에 대한 인바운드 요청에 mTLS와 승인 정책을 모두 적용하도록 지정합니다.

  4. 정책을 가져옵니다.

    gcloud network-services endpoint-policies import ep-mtls-psms \
      --source=ep-mtls-psms.yaml --location=global
    

승인 정책 검증

다음 안내에 따라 승인 정책이 올바르게 작동하는지 확인합니다.

자바

  1. 이전에 사용한 클라이언트 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  2. 명령어 셸에서 다음 명령어를 실행하여 설정을 검증합니다.

    cd grpc-java-1.42.1/examples/example-xds
    ./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \
          xds:///helloworld-gke:8000
    

    다음과 비슷한 출력이 표시됩니다.

    Greeting: Hello xds-client, from xds-server
    
  3. 대체 서버 이름을 사용해서 클라이언트를 다시 실행합니다. 이것은 실패 사례입니다. 승인 정책이 helloworld-gke:8000 호스트 이름에 대한 액세스만 허용하므로 요청이 잘못되었습니다.

    ./build/install/example-xds/bin/xds-hello-world-client --xds-creds xds-client \
          xds:///helloworld-gke-noaccess:8000
    

    다음과 비슷한 출력이 표시됩니다.

    WARNING: RPC failed: Status{code=PERMISSION_DENIED}
    

    이 출력이 표시되지 않으면 승인 정책이 아직 사용되고 있지 않은 것일 수 있습니다. 몇 분 기다렸다가 전체 확인 프로세스를 다시 시도하세요.

Go

  1. 이전에 사용한 클라이언트 포드에 대한 셸을 엽니다.

    kubectl exec -it example-grpc-client-7c969bb997-9fzjv -- /bin/bash
    
  2. 명령어 셸에서 다음 명령어를 실행하여 설정을 검증합니다.

    cd grpc-go-1.42.0/examples/features/xds/client
    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -name xds-client \
      -target xds:///helloworld-gke:8000
    

    다음과 비슷한 출력이 표시됩니다.

    Greeting: Hello xds-client, from example-grpc-server-77548868d-l9hmf
    
  3. 대체 서버 이름을 사용해서 클라이언트를 다시 실행합니다. 이것은 실패 사례입니다. 승인 정책이 helloworld-gke:8000 호스트 이름에 대한 액세스만 허용하므로 요청이 잘못되었습니다.

    GRPC_GO_LOG_VERBOSITY_LEVEL=2 GRPC_GO_LOG_SEVERITY_LEVEL="info" \
      go run main.go \
      -xds_creds \
      -name xds-client \
      -target xds:///helloworld-gke-noaccess:8000
    

    다음과 비슷한 출력이 표시됩니다.

    could not greet: rpc error: code = PermissionDenied desc = Incoming RPC is not allowed: rpc error: code = PermissionDenied desc = incoming RPC did not match an allow policy
    exit status 1
    

    이 출력이 표시되지 않으면 승인 정책이 아직 사용되고 있지 않은 것일 수 있습니다. 몇 분 기다렸다가 전체 확인 프로세스를 다시 시도하세요.

mTLS 대신 TLS 사용

이 예시에서 사용되는 TLS를 조금만 변경하면 됩니다.

  1. ServerTlsPolicy에서 mtlsPolicy를 삭제합니다.

    cat << EOF > server-tls-policy.yaml
    name: "server-tls-policy"
    serverCertificate:
      certificateProviderInstance:
        pluginInstance: google_cloud_private_spiffe
    EOF
    
  2. 대신 EndpointPolicy에서 이 정책을 사용하세요.

    cat << EOF > ep-tls-psms.yaml
    name: "ep-mtls-psms"
    type: "GRPC_SERVER"
    serverTlsPolicy: "projects/${PROJECT_ID}/locations/global/serverTlsPolicies/server-tls-policy"
    trafficPortSelector:
      ports:
      - "50051"
    endpointMatcher:
      metadataLabelMatcher:
        metadataLabelMatchCriteria: "MATCH_ALL"
        metadataLabels: []
    EOF
    
  3. mTLS용 ClientTlsPolicy도 TLS 사례에서 작동하지만 정책의 clientCertificate 섹션은 TLS에 필요하지 않으므로 삭제할 수 있습니다.

    cat << EOF > client-tls-policy.yaml
    name: "client-tls-policy"
    serverValidationCa:
    - certificateProviderInstance:
        pluginInstance: google_cloud_private_spiffe
    EOF
    

월렛 예시에서 서비스 보안 사용

이 섹션에서는 자바, C++, Go용 서비스 보안을 사용하여 월렛 예시를 사용 설정하는 방법을 간략하게 설명합니다.

자바

github에서 자바용 소스 코드 예시를 찾을 수 있습니다. 프록시리스 보안을 구성할 때 이 코드는 이미 XdsChannelXdsServer 사용자 인증 정보를 사용합니다.

이 안내에서는 Go로 월렛 예시를 구성하는 방법을 설명합니다. 자바의 경우도 비슷한 과정을 거칩니다. 이 안내에서는 Google Cloud 컨테이너 저장소에서 가져온 기존 Docker 이미지를 사용합니다.

예시를 만들려면 다음 안내를 따르세요.

  1. 저장소를 클론하고 gRPC 예시 디렉터리에 있는 파일을 가져옵니다.
  2. 00-common-env.sh 파일을 수정합니다. WALLET_DOCKER_IMAGE 값을 Go Docker 이미지로 설정하는 기존 줄을 주석 처리하고 WALLET_DOCKER_IMAGE 값을 자바 Docker 이미지로 설정하는 줄의 주석 처리를 삭제합니다.
  3. Cloud Router 인스턴스 만들기 및 구성의 안내에 따르거나 10.apis.sh 스크립트에서 create_cloud_router_instances 함수를 사용하여 Cloud Router 인스턴스를 만들고 구성합니다.
  4. hello world 예시에 대한 안내에 따르거나 20-cluster.sh 스크립트에서 create_cluster 함수를 사용하여 클러스터를 만듭니다.
  5. CA 서비스에 대한 안내에 따르거나 30-private-ca-setup.sh 스크립트를 사용하여 비공개 인증 기관을 만듭니다.
  6. 40-k8s-resources.sh 스크립트를 사용하여 모든 서비스(account, stats, stats_premium, wallet_v1, wallet_v2)의 서비스 계정, 네임스페이스, Kubernetes 서비스, NEG, 서버 측 배포 등 Kubernetes 리소스를 만듭니다.
  7. 50-td-components.sh 스크립트의 create_health_checkcreate_backend_service를 사용하여 만든 서비스마다 상태 점검과 백엔드 서비스를 만듭니다.
  8. 60-routing-components.sh 스크립트에서 create_routing_components를 사용하여 Cloud Service Mesh 라우팅 구성요소를 만듭니다.
  9. 70-security-components.sh 스크립트에서 create_security_components를 사용하여 백엔드 서비스마다 Cloud Service Mesh 보안 구성요소를 만듭니다.
  10. 75-client-deployment.sh 스크립트에서 create_client_deployment를 사용하여 월렛 클라이언트 배포를 만듭니다.
  11. grpc-wallet 클라이언트로 확인의 설명대로 클라이언트를 실행하여 구성을 확인합니다.

C++

github에서 C++용 소스 코드 예시를 찾을 수 있습니다. 프록시리스 보안을 구성할 때 이 코드는 이미 XdsChannelXdsServer 사용자 인증 정보를 사용합니다.

이 안내에서는 Go로 월렛 예시를 구성하는 방법을 설명합니다. C++의 경우도 비슷한 과정을 거칩니다. 이 안내에서는 Google Cloud 컨테이너 저장소에서 가져온 기존 Docker 이미지를 사용합니다.

예시를 만들려면 다음 안내를 따르세요.

  1. 저장소를 클론하고 gRPC 예시 디렉터리에 있는 파일을 가져옵니다.
  2. 00-common-env.sh 파일을 수정합니다. WALLET_DOCKER_IMAGE 값을 Go Docker 이미지로 설정하는 기존 줄을 주석 처리하고 WALLET_DOCKER_IMAGE 값을 C++ Docker 이미지로 설정하는 줄의 주석 처리를 삭제합니다.
  3. Cloud Router 인스턴스 만들기 및 구성의 안내에 따르거나 10.apis.sh 스크립트에서 create_cloud_router_instances 함수를 사용하여 Cloud Router 인스턴스를 만들고 구성합니다.
  4. hello world 예시에 대한 안내에 따르거나 20-cluster.sh 스크립트에서 create_cluster 함수를 사용하여 클러스터를 만듭니다.
  5. CA 서비스 안내를 따르거나 30-private-ca-setup.sh 스크립트를 사용하여 비공개 인증 기관을 만듭니다.
  6. 40-k8s-resources.sh 스크립트를 사용하여 모든 서비스(account, stats, stats_premium, wallet_v1, wallet_v2)의 서비스 계정, 네임스페이스, Kubernetes 서비스, NEG, 서버 측 배포 등 Kubernetes 리소스를 만듭니다.
  7. 50-td-components.sh 스크립트의 create_health_checkcreate_backend_service를 사용하여 만든 서비스마다 상태 점검과 백엔드 서비스를 만듭니다.
  8. 60-routing-components.sh 스크립트에서 create_routing_components를 사용하여 Cloud Service Mesh 라우팅 구성요소를 만듭니다.
  9. 70-security-components.sh 스크립트에서 create_security_components를 사용하여 백엔드 서비스마다 Cloud Service Mesh 보안 구성요소를 만듭니다.
  10. 75-client-deployment.sh 스크립트에서 create_client_deployment를 사용하여 월렛 클라이언트 배포를 만듭니다.
  11. grpc-wallet 클라이언트로 확인의 설명대로 클라이언트를 실행하여 구성을 확인합니다.

Go

Go용 소스 코드 예시는 github에서 찾을 수 있습니다. 프록시리스 보안을 구성할 때 이 코드는 이미 XdsChannelXdsServer 사용자 인증 정보를 사용합니다.

이 안내에서는 Google Cloud 컨테이너 저장소에서 가져온 기존 Docker 이미지를 사용합니다.

예시를 만들려면 다음 안내를 따르세요.

  1. 저장소를 클론하고 gRPC 예시 디렉터리에 있는 파일을 가져옵니다.
  2. 00-common-env.sh 파일을 수정하여 환경 변수에 올바른 값을 설정합니다.
  3. Cloud Router 인스턴스 만들기 및 구성의 안내에 따르거나 10.apis.sh 스크립트에서 create_cloud_router_instances 함수를 사용하여 Cloud Router 인스턴스를 만들고 구성합니다.
  4. hello world 예시에 대한 안내에 따르거나 20-cluster.sh 스크립트에서 create_cluster 함수를 사용하여 클러스터를 만듭니다.
  5. CA 서비스에 대한 안내에 따르거나 30-private-ca-setup.sh 스크립트를 사용하여 비공개 인증 기관을 만듭니다.
  6. 40-k8s-resources.sh 스크립트를 사용하여 모든 서비스(account, stats, stats_premium, wallet_v1, wallet_v2)의 서비스 계정, 네임스페이스, Kubernetes 서비스, NEG, 서버 측 배포 등 Kubernetes 리소스를 만듭니다.
  7. 50-td-components.sh 스크립트의 create_health_checkcreate_backend_service를 사용하여 만든 서비스마다 상태 점검과 백엔드 서비스를 만듭니다.
  8. 60-routing-components.sh 스크립트에서 create_routing_components를 사용하여 Cloud Service Mesh 라우팅 구성요소를 만듭니다.
  9. 70-security-components.sh 스크립트에서 create_security_components를 사용하여 백엔드 서비스마다 Cloud Service Mesh 보안 구성요소를 만듭니다.
  10. 75-client-deployment.sh 스크립트에서 create_client_deployment를 사용하여 월렛 클라이언트 배포를 만듭니다.
  11. grpc-wallet 클라이언트로 확인의 설명대로 클라이언트를 실행하여 구성을 확인합니다.

부트스트랩 파일

이 가이드의 설정 프로세스는 부트스트랩 생성기를 사용하여 필수 부트스트랩 파일을 만듭니다. 이 섹션에서는 부트스트랩 파일 자체에 대한 참조 정보를 제공합니다.

부트스트랩 파일에는 xDS 서버의 연결 정보를 포함하여 프록시리스 gRPC 코드에 필요한 구성 정보가 포함되어 있습니다. 부트스트랩 파일에는 프록시리스 gRPC 보안 기능에 필요한 보안 구성이 포함되어 있습니다. gRPC 서버에는 추가 필드 1개가 필요합니다. 샘플 부트스트랩 파일은 다음과 같습니다.

{
  "xds_servers": [
    {
      "server_uri": "trafficdirector.googleapis.com:443",
      "channel_creds": [
        {
          "type": "google_default"
        }
      ],
      "server_features": [
        "xds_v3"
      ]
    }
  ],
  "authorities": {
    "traffic-director-c2p.xds.googleapis.com": {
      "xds_servers": [
        {
          "server_uri": "dns:///directpath-pa.googleapis.com",
          "channel_creds": [
            {
              "type": "google_default"
            }
          ],
          "server_features": [
            "xds_v3",
            "ignore_resource_deletion"
          ]
        }
      ],
      "client_listener_resource_name_template": "xdstp://traffic-director-c2p.xds.googleapis.com/envoy.config.listener.v3.Listener/%s"
    }
  },
  "node": {
    "id": "projects/9876012345/networks/mesh:grpc-mesh/nodes/b59f49cc-d95a-4462-9126-112f794d5dd3",
    "cluster": "cluster",
    "metadata": {
      "INSTANCE_IP": "10.28.2.8",
      "TRAFFICDIRECTOR_DIRECTPATH_C2P_IPV6_CAPABLE": true,
      "TRAFFICDIRECTOR_GCP_PROJECT_NUMBER": "223606568246",
      "TRAFFICDIRECTOR_NETWORK_NAME": "default",
      "app": "helloworld"
    },
    "locality": {
      "zone": "us-central1-c"
    }
  },
  "certificate_providers": {
    "google_cloud_private_spiffe": {
      "plugin_name": "file_watcher",
      "config": {
        "certificate_file": "/var/run/secrets/workload-spiffe-credentials/certificates.pem",
        "private_key_file": "/var/run/secrets/workload-spiffe-credentials/private_key.pem",
        "ca_certificate_file": "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem",
        "refresh_interval": "600s"
      }
    }
  },
  "server_listener_resource_name_template": "grpc/server?xds.resource.listening_address=%s"
}

보안 서비스의 부트스트랩 파일 업데이트

다음 필드는 보안 및 xDS v3 사용과 관련된 수정사항을 반영합니다.

node 내부의 id 필드는 gRPC 클라이언트의 고유한 ID를 Cloud Service Mesh에 제공합니다. 다음 형식의 노드 ID를 사용하여 Google Cloud 프로젝트 번호와 네트워크 이름을 제공해야 합니다.

projects/{project number}/networks/{network name}/nodes/[UNIQUE_ID]

다음은 프로젝트 번호 1234의 예시이며 기본 네트워크는 다음과 같습니다.

projects/1234/networks/default/nodes/client1

INSTANCE_IP 필드는 포드의 IP 주소이거나 INADDR_ANY를 나타내는 0.0.0.0입니다. 이 필드는 서버 측 보안을 위해 gRPC 서버가 Cloud Service Mesh에서 리스너 리소스를 가져오는 데 사용됩니다.

부트스트랩 파일의 보안 구성 필드

JSON 키 유형 참고
server_listener_resource_name_template 문자열 grpc/server?xds.resource.listening_address=%s gRPC 서버에 필요합니다. gRPC는 이 값을 사용하여 서버 측 보안 및 기타 구성을 위해 Cloud Service Mesh에서 `리스너` 리소스를 가져오는 데 사용할 리소스 이름을 작성합니다. gRPC는 이 이름을 사용하여 리소스 이름 문자열을 구성합니다.
certificate_providers JSON 구조체 google_cloud_private_spiffe 필수 항목. 값은 인증서 공급자 인스턴스에 대한 이름 매핑을 나타내는 JSON 구조체입니다. 인증서 공급자 인스턴스는 ID 및 루트 인증서를 가져오는 데 사용됩니다. 예시 부트스트랩 파일의 예시에는 인증서 제공업체 인스턴스 JSON 구조체가 값인 google_cloud_private_spiffe라는 하나의 이름이 있습니다. 각 인증서 공급자 인스턴스 JSON 구조체에는 두 개의 필드가 있습니다.
  • plugin_name: 인증서 공급자에 대한 gRPC의 플러그인 아키텍처에서 요구하는 대로 사용할 인증서 공급자 플러그인을 식별하는 필수 값입니다. gRPC는 이 설정에 사용되는 파일 감시자 플러그인에 대한 지원을 기본적으로 제공합니다. plugin_name은 file_watcher입니다.
  • config입니다. file_watcher 플러그인의 JSON 구성 블로그를 식별하는 필수 값입니다. 스키마 및 콘텐츠는 플러그인에 따라 달라집니다.

file_watcher 플러그인용 config JSON 구조의 콘텐츠는 다음과 같습니다.

  • certificate_file: 필수 문자열. 이 값은 ID 인증서의 위치입니다.
  • private_key_file: 필수 문자열. 이 값은 비공개 키 파일의 위치이며 ID 인증서와 일치해야 합니다.
  • ca_certificate_file: 필수 문자열. 이 값은 루트 인증서의 위치로, 트러스트 번들이라고도 합니다.
  • refresh_interval: 선택사항 문자열. 이 값은 기간의 JSON 매핑에 대한 문자열 표현을 사용하여 지정된 새로고침 간격을 나타냅니다. 기본값은 10분인 '600s'입니다.

부트스트랩 생성기

부트스트랩 생성기 컨테이너 이미지는 gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0에서 사용할 수 있습니다. 소스 코드는 https://github.com/GoogleCloudPlatform/traffic-director-grpc-bootstrap에서 사용할 수 있습니다. 가장 일반적으로 사용되는 명령줄 옵션은 다음과 같습니다.

  • --output: 이 옵션을 사용하여 출력 부트스트랩 파일을 작성할 위치를 지정합니다. 예를 들어 --output /tmp/bootstrap/td-grpc-bootstrap.json 명령어는 포드 파일 시스템의 /tmp/bootstrap/td-grpc-bootstrap.json에 부트스트랩 파일을 생성합니다.
  • --config-mesh-experimental: 이 옵션을 사용하여 Mesh 리소스와 일치하는 메시 이름을 지정합니다.
  • --node-metadata: 이 플래그를 사용하여 부트스트랩 파일에서 노드 메타데이터를 채웁니다. 이는 EndpointPolicy에서 메타데이터 라벨 일치자를 사용할 때 필요합니다. 여기서 Cloud Service Mesh는 부트스트랩 파일의 노드 메타데이터 섹션에 제공된 라벨 데이터를 사용합니다. 인수는 키=값 형식으로 제공됩니다. 예: --node-metadata version=prod --node-metadata type=grpc

이전 정보는 부트스트랩 파일의 노드 메타데이터 섹션에 다음을 추가합니다.

{
  "node": {
...
    "metadata": {
      "version": "prod",
      "type": "grpc",
...
    },
...
  },
...
}

배포 삭제

필요한 경우 이러한 명령어를 실행하여 이 가이드를 통해 만든 배포를 삭제할 수 있습니다.

클러스터를 삭제하려면 다음 명령어를 실행합니다.

gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet

만든 리소스를 삭제하려면 다음 명령어를 실행합니다.

gcloud compute backend-services delete grpc-gke-helloworld-service --global --quiet
gcloud compute network-endpoint-groups delete example-grpc-server --zone ZONE --quiet
gcloud compute firewall-rules delete grpc-gke-allow-health-checks --quiet
gcloud compute health-checks delete grpc-gke-helloworld-hc --quiet
gcloud network-services endpoint-policies delete ep-mtls-psms \
    --location=global --quiet
gcloud network-security authorization-policies delete helloworld-gke-authz-policy \
   --location=global --quiet
gcloud network-security client-tls-policies delete client-mtls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-tls-policy \
    --location=global --quiet
gcloud network-security server-tls-policies delete server-mtls-policy \
    --location=global --quiet

문제 해결

다음 안내를 따라 보안 배포 문제를 해결할 수 있습니다.

워크로드가 Cloud Service Mesh에서 구성을 가져올 수 없음

다음과 유사한 오류가 표시되는 경우:

PERMISSION_DENIED: Request had insufficient authentication scopes.

다음 사항이 지켜졌는지 확인하세요.

  • --scopes=cloud-platform 인수를 사용하여 GKE 클러스터를 만들었습니다.
  • Kuberneters 서비스 계정에 roles/trafficdirector.client를 할당했습니다.
  • roles/trafficdirector.client를 기본 Google Cloud 서비스 계정(위의 ${GSA_EMAIL})에 할당했습니다.
  • trafficdirector.googleapis.com 서비스(API)를 사용 설정했습니다.

올바른 Cloud Service Mesh 구성이 있어도 gRPC 서버에서 TLS/mTLS를 사용하지 않음

엔드포인트 정책 구성에 GRPC_SERVER를 지정해야 합니다. SIDECAR_PROXY를 지정하면 gRPC에서 구성을 무시합니다.

요청한 클러스터 버전으로 GKE 클러스터를 만들 수 없음

GKE 클러스터 생성 명령어가 다음과 같은 오류와 함께 실패할 수 있습니다.

Node version "1.20.5-gke.2000" is unsupported.

클러스터 생성 명령어에 --release-channel rapid 인수를 사용하고 있는지 확인합니다. 이 출시 버전에 적합한 버전을 가져오려면 빠른 출시 채널을 사용해야 합니다.

No usable endpoint 오류가 표시됨

No usable endpoint 오류로 인해 클라이언트가 서버와 통신할 수 없는 경우 상태 확인기가 서버 백엔드를 비정상으로 표시했을 수 있습니다. 백엔드 상태를 확인하려면 다음 gcloud 명령어를 실행합니다.

gcloud compute backend-services get-health grpc-gke-helloworld-service --global

명령어가 백엔드 상태를 비정상 상태로 반환하는 원인은 다음 중 하나일 수 있습니다.

  • 방화벽이 생성되지 않았거나 올바른 소스 IP 범위가 없음
  • 방화벽의 대상 태그가 생성된 클러스터의 태그와 일치하지 않음

보안 설정에서 워크로드가 통신할 수 없음

프록시리스 서비스 메시의 보안을 설정한 후 워크로드가 통신할 수 없으면 다음 안내에 따라 원인을 확인하세요.

  1. 프록시리스 보안을 사용 중지하고 프록시리스 서비스 메시 부하 분산 사용 사례에서 문제를 제거합니다. 메시에서 보안을 사용 중지하려면 다음 중 하나를 실행합니다.
    1. 클라이언트 측과 서버 측에서 일반 텍스트 사용자 인증 정보를 사용합니다. 또는
    2. Cloud Service Mesh 구성에서 백엔드 서비스와 엔드포인트 정책의 보안을 구성하지 않습니다.

배포에 보안 설정이 없으므로 프록시리스 Cloud Service Mesh 배포 문제 해결의 단계를 수행합니다.

  1. 일반 텍스트 또는 안전하지 않은 사용자 인증 정보와 함께 xDS 사용자 인증 정보를 대체 사용자 인증 정보로 사용하도록 워크로드를 수정합니다. 앞에서 설명한 대로 보안을 중지한 상태에서 Cloud Service Mesh 구성을 유지합니다. 이 경우 gRPC가 Cloud Service Mesh에서 보안을 구성하도록 허용하더라도 Cloud Service Mesh는 보안 정보를 전송하지 않습니다. 이러한 경우에는 gRPC는 앞선 첫 번째 경우와 유사하게 작동해야 하는 일반 텍스트(또는 안전하지 않은) 사용자 인증 정보로 대체해야 합니다. 이 방법으로 문제가 해결되지 않으면 다음을 실행합니다.

    1. gRPC 및 Cloud Service Mesh 간에 교환되는 xDS 메시지를 확인할 수 있도록 클라이언트 측과 서버 측 모두에서 로깅 수준을 늘립니다.
    2. Cloud Service Mesh가 워크로드로 전송되는 CDS 및 LDS 응답에서 보안을 사용 설정하지 않았다는 것을 확인합니다.
    3. 워크로드가 채널에서 TLS 또는 mTLS 모드를 사용하지 않는지 확인합니다. TLS 핸드셰이크 관련 로그 메시지가 표시되면 애플리케이션 소스 코드에서 안전하지 않거나 일반 텍스트를 대체 사용자 인증 정보로 사용하고 있는지 확인합니다. 애플리케이션 소스 코드가 올바른 경우 이는 gRPC 라이브러리의 버그일 수 있습니다.
  2. 사용자 가이드의 문제해결 단계에 따라 GKE와 CA 서비스 통합이 GKE 클러스터에 올바르게 작동하는지 확인합니다. 이 기능에서 제공하는 인증서 및 키를 지정된 디렉터리 /var/run/secrets/workload-spiffe-credentials/에서 사용할 수 있는지 확인합니다.

  3. 앞에서 설명한 대로 메시에서 mTLS 대신 TLS를 사용 설정하고 클라이언트와 서버 워크로드를 다시 시작합니다.

    1. gRPC 및 Cloud Service Mesh 간에 교환되는 xDS 메시지를 확인하려면 클라이언트 측과 서버 측 모두에서 로깅 수준을 늘립니다.
    2. Cloud Service Mesh가 워크로드에 전송되는 CDS 및 LDS 응답에서 보안을 사용 설정했는지 확인합니다.

클라이언트가 CertificateExceptionPeer certificate SAN check failed 메시지와 함께 실패함

SecuritySettings 메시지의 subjectAltNames 값에 문제가 있음을 나타냅니다. 이 값은 백엔드 서비스를 위해 만든 Kubernetes 서비스를 기반으로 합니다. 생성된 모든 Kubernetes 서비스에는 다음과 같은 형식의 SPIFFE ID가 연결되어 있습니다.

spiffe://${WORKLOAD_POOL}/ns/${K8S_NAMESPACE}/sa/${SERVICE_ACCOUNT}

이 값은 다음과 같습니다.

  • WORKLOAD_POOL: 클러스터의 워크로드 풀인 ${PROJECT_ID}.svc.id.goog
  • K8S_NAMESPACE: 서비스 배포에 사용한 Kubernetes 네임스페이스
  • SERVICE_ACCOUNT: 서비스 배포에서 사용한 Kubernetes 서비스 계정

백엔드 서비스에 네트워크 엔드포인트 그룹으로 연결한 모든 Kubernetes 서비스에 대해 SPIFFE ID를 올바르게 계산하고 SPIFFE ID를 SecuritySettings 메시지의 subjectAltNames 필드에 추가했는지 확인합니다.

애플리케이션이 gRPC 라이브러리에 mTLS 인증서를 사용할 수 없음

애플리케이션이 gRPC 라이브러리에서 mTLS 인증서를 사용할 수 없는 경우 다음을 실행합니다.

  1. NEG를 사용하여 프록시리스 gRPC 서비스 만들기에 설명된 security.cloud.google.com/use-workload-certificates 주석이 포드 사양에 포함되어 있는지 확인합니다.

  2. 포드 내의 다음 경로에서 리프 인증서, 비공개 키, 신뢰할 수 있는 CA 인증서와 함께 인증서 체인이 포함된 파일에 액세스할 수 있는지 확인합니다.

    1. 리프 인증서가 있는 인증서 체인: '/var/run/secrets/workload-spiffe-credentials/certificates.pem'
    2. 비공개 키: "/var/run/secrets/workload-spiffe-credentials/private_key.pem"
    3. CA 번들: '/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem'
  3. 이전 단계의 인증서를 사용할 수 없는 경우 다음 안내를 따릅니다.

      gcloud privateca subordinates describe SUBORDINATE_CA_POOL_NAME 
    --location=LOCATION

    1. GKE의 제어 영역에 올바른 IAM 역할 binding이 있는지 확인하여 CA 서비스에 대한 액세스 권한을 부여합니다.

      # Get the IAM policy for the CA
      gcloud privateca roots get-iam-policy ROOT_CA_POOL_NAME
      
      # Verify that there is an IAM binding granting access in the following format
      - members:
      - serviceAccount:service-projnumber@container-engine-robot.iam.gserviceaccount.com
      role: roles/privateca.certificateManager
      
      # Where projnumber is the project number (e.g. 2915810291) for the GKE cluster.
      
    2. 인증서가 만료되지 않은 것을 확인합니다. /var/run/secrets/workload-spiffe-credentials/certificates.pem의 인증서 체인 및 리프 인증서입니다. 다음 명령어를 실행하여 확인합니다.

      cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
      

    3. 다음 명령어를 실행하여 애플리케이션에서 키 유형을 지원하는지 확인합니다.

      cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
      

    4. gRPC 자바 애플리케이션에 WorkloadCertificateConfig YAML 파일의 다음 keyAlgorithm이 있는지 확인합니다.

      keyAlgorithm:
        rsa:
          modulusSize: 4096
    
  4. CA가 인증서 키와 동일한 키 계열을 사용하는지 확인합니다.

애플리케이션의 인증서가 클라이언트, 서버 또는 피어에서 거부됨

  1. 피어 애플리케이션이 동일한 트러스트 번들을 사용하여 인증서를 확인하는지 확인합니다.
  2. 사용 중인 인증서가 만료되지 않았는지 확인합니다(리프 인증서가 있는 인증서 체인: '/var/run/secrets/workload-spiffe-credentials/certificates.pem').

포드가 대기 중 상태로 유지됨

설정 프로세스 중에 포드가 대기중 상태로 유지되면 배포 사양에서 포드의 CPU 및 메모리 리소스를 늘립니다.

--enable-mesh-certificates 플래그로 클러스터를 만들 수 없음

최신 버전의 gcloud CLI를 실행 중인지 확인합니다.

gcloud components update

--enable-mesh-certificates 플래그는 gcloud beta에서만 작동합니다.

포드가 시작되지 않음

인증서 프로비저닝이 실패하면 GKE 메시 인증서를 사용하는 포드가 시작되지 않을 수 있습니다. 다음과 같은 경우 이 오류가 발생할 수 있습니다.

  • WorkloadCertificateConfig 또는 TrustConfig가 잘못 구성되었거나 누락됨
  • CSR이 승인되지 않음

포드 이벤트를 확인하여 인증서 프로비저닝에 실패했는지 확인할 수 있습니다.

  1. 포드 상태를 확인합니다.

    kubectl get pod -n POD_NAMESPACE POD_NAME
    

    다음을 바꿉니다.

    • POD_NAMESPACE: 포드의 네임스페이스입니다.
    • POD_NAME: 포드의 이름입니다.
  2. 포드의 최근 이벤트를 확인합니다.

    kubectl describe pod -n POD_NAMESPACE POD_NAME
    
  3. 인증서 프로비저닝에 실패하면 Type=Warning, Reason=FailedMount, From=kubelet, MountVolume.SetUp failed for volume "gke-workload-certificates"로 시작하는 Message 필드가 있는 이벤트가 표시됩니다. Message 필드에는 문제 해결 정보가 포함됩니다.

    Events:
      Type     Reason       Age                From       Message
      ----     ------       ----               ----       -------
      Warning  FailedMount  13s (x7 over 46s)  kubelet    MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)
    
  4. 객체가 잘못 구성되었거나 CSR이 거부되어 포드가 시작되지 않는 경우 다음 문제 해결 단계를 참조하세요.

WorkloadCertificateConfig 또는 TrustConfig가 잘못 구성됨

WorkloadCertificateConfigTrustConfig 객체를 올바르게 만들었는지 확인하세요. kubectl을 사용하여 이러한 객체 중 하나에서 잘못된 구성을 진단할 수 있습니다.

  1. 현재 상태를 검색합니다.

    WorkloadCertificateConfig의 경우:

    kubectl get WorkloadCertificateConfig default -o yaml
    

    TrustConfig의 경우:

    kubectl get TrustConfig default -o yaml
    
  2. 상태 출력을 검사합니다. 유효한 객체에는 type: Readystatus: "True" 조건이 있습니다.

    status:
      conditions:
      - lastTransitionTime: "2021-03-04T22:24:11Z"
        message: WorkloadCertificateConfig is ready
        observedGeneration: 1
        reason: ConfigReady
        status: "True"
        type: Ready
    

    잘못된 객체의 경우 대신 status: "False"가 표시됩니다. reasonmessage 필드에는 추가 문제 해결 세부정보가 포함되어 있습니다.

CSR이 승인되지 않음

CSR 승인 프로세스 중에 문제가 발생하면 CSR의 type: Approvedtype: Issued 조건에서 오류 세부정보를 확인하세요.

  1. kubectl을 사용하여 관련 CSR을 나열합니다.

    kubectl get csr \
      --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'
    
  2. Issued가 아닌 Approved거나 Approved가 아닌 CSR을 선택합니다.

  3. kubectl을 사용하여 선택한 CSR의 세부정보를 가져옵니다.

    kubectl get csr CSR_NAME -o yaml
    

    CSR_NAME을 선택한 CSR의 이름으로 바꿉니다.

유효한 CSR에는 type: Approvedstatus: "True"의 조건이 있고 status.certificate 필드에는 유효한 인증서가 있습니다.

status:
  certificate: <base64-encoded data>
  conditions:
  - lastTransitionTime: "2021-03-04T21:58:46Z"
    lastUpdateTime: "2021-03-04T21:58:46Z"
    message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
    reason: AutoApproved
    status: "True"
    type: Approved

잘못된 CSR의 문제 해결 정보는 messagereason 필드에 표시됩니다.

포드에 인증서가 없음

  1. 포드의 포드 사양을 가져옵니다.

    kubectl get pod -n POD_NAMESPACE POD_NAME -o yaml
    

    다음을 바꿉니다.

    • POD_NAMESPACE: 포드의 네임스페이스입니다.
    • POD_NAME: 포드의 이름입니다.
  2. mTLS 사용자 인증 정보를 수신하도록 포드 구성하기에 설명된 security.cloud.google.com/use-workload-certificates 주석이 포드 사양에 포함되어 있는지 확인합니다.

  3. GKE 메시 인증서 허용 컨트롤러가 workloadcertificates.security.cloud.google.com 유형의 CSI 드라이버 볼륨을 포드 사양에 성공적으로 삽입했는지 확인합니다.

    volumes:
    ...
    -csi:
      driver: workloadcertificates.security.cloud.google.com
      name: gke-workload-certificates
    ...
    
  4. 각 컨테이너에 볼륨 마운트가 있는지 확인합니다.

    containers:
    - name: ...
      ...
      volumeMounts:
      - mountPath: /var/run/secrets/workload-spiffe-credentials
        name: gke-workload-certificates
        readOnly: true
      ...
    
  5. 포드의 다음 위치에서 다음 인증서 번들 및 비공개 키를 사용할 수 있는지 확인합니다.

    • 인증서 체인 번들: /var/run/secrets/workload-spiffe-credentials/certificates.pem
    • 비공개 키: /var/run/secrets/workload-spiffe-credentials/private_key.pem
    • CA 신뢰 앵커 번들: /var/run/secrets/workload-spiffe-credentials/ca_certificates.pem
  6. 이 파일을 사용할 수 없으면 다음 단계를 수행합니다.

    1. 클러스터의 CA 서비스(미리보기) 인스턴스를 검색합니다.

      kubectl get workloadcertificateconfigs default -o jsonpath '{.spec.certificateAuthorityConfig.certificateAuthorityServiceConfig.endpointURI}'
      
    2. CA 서비스(미리보기) 인스턴스의 상태를 검색합니다.

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
        --location ISSUING_CA_LOCATION
      

      다음을 바꿉니다.

      • ISSUING_CA_TYPE: 발급 CA 유형으로서 subordinates 또는 roots이어야 합니다.
      • ISSUING_CA_NAME: 발급 CA의 이름입니다.
      • ISSUING_CA_LOCATION: 발급 CA의 리전입니다.
    3. 루트 CA의 IAM 정책을 가져옵니다.

      gcloud privateca roots get-iam-policy ROOT_CA_NAME
      

      ROOT_CA_NAME을 루트 CA의 이름으로 바꿉니다.

    4. IAM 정책에서 privateca.auditor 정책 binding이 있는지 확인합니다.

      ...
      - members:
        - serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
        role: roles/privateca.auditor
      ...
      

      이 예시에서 PROJECT_NUMBER는 클러스터의 프로젝트 번호입니다.

    5. 하위 CA의 IAM 정책을 가져옵니다.

      gcloud privateca subordinates get-iam-policy SUBORDINATE_CA_NAME
      

      SUBORDINATE_CA_NAME을 하위 CA 이름으로 바꿉니다.

    6. IAM 정책에서 privateca.certificateManager 정책 binding이 있는지 확인합니다.

      ...
      - members:
        - serviceAccount: service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
        role: roles/privateca.certificateManager
      ...
      

      이 예시에서 PROJECT_NUMBER는 클러스터의 프로젝트 번호입니다.

애플리케이션이 발급된 mTLS 사용자 인증 정보를 사용할 수 없음

  1. 인증서가 만료되지 않은 것을 확인합니다.

    cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
    
  2. 사용한 키 유형이 애플리케이션에서 지원되는지 확인합니다.

    cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
    
  3. 발급 CA가 인증서 키와 동일한 키 계열을 사용하는지 확인합니다.

    1. CA 서비스(미리보기) 인스턴스의 상태를 가져옵니다.

      gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
        --location ISSUING_CA_LOCATION
      

      다음을 바꿉니다.

      • ISSUING_CA_TYPE: 발급 CA 유형으로서 subordinates 또는 roots이어야 합니다.
      • ISSUING_CA_NAME: 발급 CA의 이름입니다.
      • ISSUING_CA_LOCATION: 발급 CA의 리전입니다.
    2. 출력의 keySpec.algorithmWorkloadCertificateConfig YAML 매니페스트에서 정의한 것과 동일한 키 알고리즘인지 확인합니다. 출력 형식은 다음과 같습니다.

      config:
        ...
        subjectConfig:
          commonName: td-sub-ca
          subject:
            organization: TestOrgLLC
          subjectAltName: {}
      createTime: '2021-05-04T05:37:58.329293525Z'
      issuingOptions:
        includeCaCertUrl: true
      keySpec:
        algorithm: RSA_PKCS1_2048_SHA256
       ...
      

인증서가 거부됨

  1. 피어 애플리케이션이 동일한 트러스트 번들을 사용하여 인증서를 확인하는지 확인합니다.
  2. 인증서가 만료되지 않은 것을 확인합니다.

    cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
    
  3. gRPC Go Credentials Reloading API를 사용하지 않는 경우 클라이언트 코드가 정기적으로 파일 시스템에서 사용자 인증 정보를 새로고침하는지 확인합니다.

  4. 워크로드가 CA와 동일한 트러스트 도메인에 있는지 확인합니다. GKE 메시 인증서는 단일 트러스트 도메인에서 워크로드 간 통신을 지원합니다.

제한사항

Cloud Service Mesh 서비스 보안은 GKE에서만 지원됩니다. Compute Engine으로는 서비스 보안을 배포할 수 없습니다.

Cloud Service Mesh는 엔드포인트와 일치하는 엔드포인트 정책 리소스가 2개 이상 있는 시나리오를 지원하지 않습니다(예: 같은 라벨과 포트가 있는 정책 2개 또는 엔드포인트 라벨과 일치하는 서로 다른 라벨이 있는 정책 2개 이상). 엔드포인트 정책을 엔드포인트 라벨과 일치시키는 방법에 대한 자세한 내용은 EndpointPolicy.EndpointMatcher.MetadataLabelMatcher의 API를 참조하세요. 이러한 경우 Cloud Service Mesh는 충돌하는 정책에서 보안 구성을 생성하지 않습니다.