Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

Envoy로 서비스 보안 설정

이 가이드의 안내에 따라 Cloud Service Mesh 및 Envoy 프록시를 사용하여 배포된 서비스에 대한 인증과 승인을 구성하세요. Cloud Service Mesh 서비스 보안에 대한 자세한 내용은 Cloud Service Mesh 서비스 보안을 참조하세요.

요구사항

Envoy를 사용하여 Cloud Service Mesh의 서비스 보안을 구성하기 전에 다음 기본 요건을 충족하도록 유의하세요.

Cloud Service Mesh를 배포하는 데 필요한 모든 요구사항을 충족해야 합니다. 이러한 요구사항에 대한 자세한 내용은 Envoy 및 프록시리스 워크로드로 서비스 라우팅 API 설정 준비를 참고하세요.
Envoy 및 프록시리스 워크로드로 서비스 라우팅 API 설정 준비에 설명된 대로 서비스 보안을 사용하도록 Cloud Service Mesh 및 Google Cloud 서비스 메시 리소스를 만들거나 업데이트할 수 있는 충분한 권한이 있어야 합니다.

설정 준비

다음 섹션에서는 Cloud Service Mesh 보안 서비스를 설정하기 전에 완료해야 하는 태스크에 대해 설명합니다. 해당하는 사전 작업은 다음과 같습니다.

Google Cloud CLI 업데이트
변수 설정
Cloud Service Mesh가 Certificate Authority Service와 함께 작동하는 데 필요한 API 사용 설정

`gcloud` 명령줄 도구 업데이트

Google Cloud CLI를 업데이트하려면 로컬 머신에서 다음을 실행합니다.

gcloud components update

변수 설정

이 문서의 예시를 따라가면서 일관된 값을 사용하여 코드를 복사하고 붙여넣을 수 있도록 다음 변수를 설정합니다. 다음 값을 사용하세요.

PROJECT_ID: 프로젝트의 ID로 대체합니다.
CLUSTER_NAME: 사용할 클러스터 이름을 바꿉니다(예: secure-td-cluster).
ZONE: 클러스터가 있는 영역으로 대체합니다.
GKE_CLUSTER_URL: https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME 대체
WORKLOAD_POOL: PROJECT_ID.svc.id.goog 대체
K8S_NAMESPACE: default 대체
DEMO_CLIENT_KSA: 클라이언트 Kubernetes 서비스 계정의 이름으로 대체합니다.
DEMO_SERVER_KSA: 서버 Kubernetes 서비스 계정의 이름으로 대체합니다.
PROJNUM: Google Cloud 콘솔 또는 다음 명령어를 사용하여 확인할 수 있는 프로젝트 번호로 대체합니다.
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
SA_GKE: service-PROJNUM@container-engine-robot.iam.gserviceaccount.com 대체
CLUSTER_VERSION: 사용 가능한 최신 버전으로 대체합니다. 신속 채널 출시 노트에서 확인할 수 있습니다. 최소 필수 버전은 1.21.4-gke.1801입니다. 이 예시에서 사용할 GKE 클러스터 버전입니다.

여기에서 값을 설정합니다.

# Substitute your project ID
PROJECT_ID=PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME=CLUSTER_NAME
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=K8S_NAMESPACE
DEMO_CLIENT_KSA=DEMO_CLIENT_KSA
DEMO_SERVER_KSA=DEMO_SERVER_KSA

# Compute other values
# Project number for your project
PROJNUM=PROJNUM

CLUSTER_VERSION=CLUSTER_VERSION
SA_GKE=service-PROJNUM@container-engine-robot.iam.gserviceaccount.com

API 사용 설정

gcloud services enable 명령어를 사용하여 Certificate Authority Service로 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

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

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

최소 클러스터 버전 1.21.4-gke.1801을 사용합니다. 이후 버전의 기능이 필요한 경우 빠른 출시 채널에서 해당 버전을 가져올 수 있습니다.
인증서를 발급하는 인증 기관 만들기의 설명대로 메시 인증서로 GKE 클러스터를 사용 설정하고 구성해야 합니다.

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
```
클러스터 생성이 완료되는 데 몇 분 정도 걸릴 수 있습니다.
기존 클러스터를 사용하는 경우 GKE용 워크로드 아이덴티티 제휴 및 GKE 메시 인증서를 사용 설정합니다. 클러스터가 update 명령어와 함께 사용할 수 없는 --enable-ip-alias 플래그로 생성되었는지 확인합니다.
```
gcloud container clusters update CLUSTER_NAME \
  --enable-mesh-certificates
```
다음 명령어를 실행하여 kubectl 명령어의 기본 클러스터로 새 클러스터로 전환합니다.
```
gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE
```

멀티 클러스터 환경에 배포

멀티 클러스터 환경에 배포하는 경우 이 섹션에 설명된 일반적인 절차를 따릅니다. 이 안내에서는 클라이언트 포드가 하나의 클러스터에서 실행되고 서버 포드가 다른 클러스터에서 실행된다고 가정합니다.

이전 섹션의 안내에 따라 클러스터를 만들거나 업데이트합니다.

다음 명령어를 사용하여 각 클러스터의 포드 IP 주소 범위를 캡처합니다.

gcloud compute firewall-rules list \
  --filter="name~gke-{CLUSTER_NAME}-[0-9a-z]*-all" \
  --format="value(sourceRanges)"

예를 들어 cluster-a 및 cluster-b라는 클러스터에 대해 명령어를 실행하면 다음 결과가 반환됩니다.

cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node
cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node

클러스터가 서로 통신할 수 있게 해주는 VPC 방화벽 규칙을 만듭니다. 예를 들어 다음 명령어는 cluster-a 포드 IP 주소가 cluster-b 노드와 통신할 수 있게 해주는 방화벽 규칙을 만듭니다.
```
gcloud compute firewall-rules create per-cluster-a-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-b-acd14479-node"
```
다음 명령어는 cluster-b 포드 IP 주소가 cluster-a 노드와 통신하도록 허용하는 방화벽 규칙을 만듭니다.
```
gcloud compute firewall-rules create per-cluster-b-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-a-9cd18751-node"
```

Fleet에 클러스터 등록

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

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

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.
```

생성된 매니페스트 파일을 클러스터에 적용합니다.

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

클러스터에서 멤버십 리소스를 가져옵니다.
```
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

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

루트 CA 서비스 풀을 만듭니다.

gcloud privateca pools create ROOT_CA_POOL_NAME \
  --location ROOT_CA_POOL_LOCATION \
  --tier enterprise

루트 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"

하위 풀과 하위 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

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"

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"

클러스터에 메시 인증서를 발급하는 방법을 알리도록 다음 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
```

발급된 인증서를 신뢰하는 방법을 클러스터에 지정하기 위해 다음 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

클러스터에 구성을 적용합니다.

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

Identity and Access Management 구성

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

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

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

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

다음 안내에 따라 기본 서비스 계정이 Cloud Service Mesh Security API에 액세스하고 Kubernetes 서비스 계정을 만들 수 있습니다.

기본 서비스 계정이 Cloud Service Mesh Security API에 액세스할 수 있도록 IAM을 구성합니다.

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

Kubernetes 서비스 계정을 설정합니다. 다음 섹션의 클라이언트 및 서버 배포는 Kubernetes 서버 및 클라이언트 서비스 계정의 Kname을 사용합니다.
```
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
```

두 계정 간에 IAM 정책 binding을 만들어 Kubernetes 서비스 계정이 기본 Compute Engine 서비스 계정을 가장할 수 있도록 허용합니다. 이 binding을 사용하면 Kubernetes 서비스 계정이 기본 Compute Engine 서비스 계정 역할을 수행할 수 있습니다.

gcloud iam service-accounts add-iam-policy-binding  \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_SERVER_KSA]" ${GSA_EMAIL}

gcloud iam service-accounts add-iam-policy-binding  \
  --role roles/iam.workloadIdentityUser  \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_CLIENT_KSA]" ${GSA_EMAIL}

Kubernetes 서비스 계정을 주석 처리하여 기본 Compute Engine 서비스 계정과 연결하세요.

kubectl annotate --namespace K8S_NAMESPACE \
  serviceaccount DEMO_SERVER_KSA \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

kubectl annotate --namespace K8S_NAMESPACE \
  serviceaccount DEMO_CLIENT_KSA \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

Cloud Service Mesh 설정

다음 안내에 따라 사이드카 인젝터를 설치하고, 테스트 서비스를 설정하고, 다른 배포 작업을 완료합니다.

클러스터에 Envoy 사이드카 인젝터 설치

자동 Envoy 삽입으로 GKE 포드용 Cloud Service Mesh 설정 섹션 두 개의 안내에 따라 클러스터에 Envoy 사이드카 삽입을 배포하고 사용 설정합니다.

프로젝트 정보 구성
MutatingWebhookConfigurations 설치 메시 이름을 sidecar_mesh로, 네트워크를 빈 문자열 ""로 구성해야 합니다.
사이드카 삽입 사용 설정

테스트 서비스를 설정하기 전에 두 가지 안내를 모두 완료해야 합니다.

테스트 서비스 설정

Envoy 사이드카 인젝터를 설치한 후 다음 안내에 따라 배포용 테스트 서비스를 설정합니다.

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/service_sample.yaml | sed -e s/DEMO_SERVER_KSA_PLACEHOLDER/DEMO_SERVER_KSA/g > service_sample.yaml

kubectl apply -f service_sample.yaml

service_sample.yaml 파일에는 데모 서버 애플리케이션의 podspec이 포함됩니다. Cloud Service Mesh 보안과 관련된 몇 가지 주석이 있습니다.

Cloud Service Mesh 프록시 메타데이터

PodSpec은 proxyMetadata 주석을 지정합니다.

spec:
...
      annotations:
        cloud.google.com/proxyMetadata: '{"app": "payments"}'
...

포드가 초기화되면 사이드카 프록시가 이 주석을 선택하여 Cloud Service Mesh로 전송합니다. 그러면 Cloud Service Mesh가 이 정보를 사용하여 필터링된 구성을 다시 보낼 수 있습니다.

이 가이드의 뒷부분에서는 엔드포인트 정책이 엔드포인트 일치자를 지정합니다.
엔드포인트 일치자는 이름이 app이고 값이 payments인 라벨을 제공하는 클라이언트만 필터링된 구성을 수신하도록 지정합니다.

CA 서비스에서 서명한 메시 인증서 및 키 사용

PodSpec은 enableManagedCerts 주석을 지정합니다.

spec:
...
      annotations:
        ...
        cloud.google.com/enableManagedCerts: "true"
...

포드가 초기화되면 CA 서비스 서명 인증서 및 키가 로컬 사이드카 프록시 파일 시스템에 자동으로 마운트됩니다.

인바운드 트래픽 가로채기 포트 구성

PodSpec은 includeInboundPorts 주석을 지정합니다.

spec:
...
      annotations:
        ...
        cloud.google.com/includeInboundPorts: "8000"
...

이 포트는 서버 애플리케이션에서 연결을 리슨하는 포트입니다. 포드가 초기화되면 사이드카 프록시가 이 주석을 선택하여 Cloud Service Mesh로 전송합니다. 그러면 Cloud Service Mesh에서 이 정보를 사용하여 이 포트로 수신되는 모든 트래픽을 가로채고 포트에 보안 정책을 적용할 수 있는 필터링된 구성을 다시 보낼 수 있습니다.

상태 확인 포트는 애플리케이션 포트와 달라야 합니다. 그렇지 않으면 동일한 보안 정책이 상태 확인 포트로의 수신 연결에 적용되어 연결이 거부되고 서버가 비정상으로 잘못 표시될 수 있습니다.

NEG로 GKE 서비스 구성

GKE 서비스는 Cloud Service Mesh 백엔드 서비스의 백엔드로 구성할 수 있도록 네트워크 엔드포인트 그룹(NEG)을 통해 노출해야 합니다. 이 설정 가이드와 함께 제공되는 service_sample.yaml 패키지는 다음 주석에서 NEG 이름 service-test-neg를 사용합니다.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

service_sample.yaml 파일은 변경할 필요가 없습니다.

NEG 이름 저장

NEG 이름을 NEG_NAME 변수에 저장합니다.

NEG_NAME="service-test-neg"

GKE에 클라이언트 애플리케이션 배포

다음 명령어를 실행하여 보안 기능을 시연해야 하는 사이드카로 Envoy 프록시를 사용하여 데모 클라이언트를 실행합니다.

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/client_sample.yaml | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > client_sample.yaml

kubectl apply -f client_sample.yaml

클라이언트 podspec에는 enableManagedCerts 주석만 포함됩니다. 이렇게 해야 CA 서비스 인스턴스에서 서명한 GKE 관리형 메시 인증서와 키에 필요한 볼륨을 마운트할 수 있습니다.

상태 점검, 방화벽 규칙, 백엔드 서비스 리소스 구성

이 섹션에서는 Cloud Service Mesh의 상태 점검, 방화벽 규칙, 백엔드 서비스 리소스를 만듭니다.

상태 확인을 만듭니다.

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

상태 확인기 IP 주소 범위를 허용하는 방화벽 규칙을 만듭니다.

gcloud compute firewall-rules create fw-allow-health-checks \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --rules tcp

백엔드 서비스를 만들고 상태 확인을 백엔드 서비스에 연결합니다.

gcloud compute backend-services create td-gke-service \
  --global \
  --health-checks td-gke-health-check \
  --load-balancing-scheme INTERNAL_SELF_MANAGED

이전에 만든 NEG를 백엔드 서비스에 백엔드로 추가합니다.

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

`Mesh` 및 `HTTPRoute` 리소스 구성

이 섹션에서는 Mesh 및 HTTPRoute 리소스를 만듭니다.

Mesh 리소스 사양을 만들고 mesh.yaml 파일에 저장합니다.
```
name: sidecar-mesh
interceptionPort: 15001
```
mesh.yaml 파일에 지정하지 않으면 가로채기 포트의 기본값은 15001입니다.

mesh.yaml 사양을 사용하여 Mesh 리소스를 만듭니다.

gcloud network-services meshes import sidecar-mesh \
  --source=mesh.yaml \
  --location=global

HTTPRoute 사양을 만들고 http_route.yaml 파일에 저장합니다.

PROJECT_ID 또는 PROJECT_NUMBER를 사용할 수 있습니다.

name: helloworld-http-route
hostnames:
- service-test
meshes:
- projects/PROJNUM/locations/global/meshes/sidecar-mesh
rules:
- action:
   destinations:
   - serviceName: "projects/PROJNUM/locations/global/backendServices/td-gke-service"

http_route.yaml 파일의 사양을 사용하여 HTTPRoute 리소스를 만듭니다.

gcloud network-services http-routes import helloworld-http-route \
  --source=http_route.yaml \
  --location=global

Cloud Service Mesh 구성이 완료되었습니다. 이제 인증 정책과 승인 정책을 구성할 수 있습니다.

서비스 간 보안 설정

다음 섹션의 안내를 따라 서비스 간 보안을 설정합니다.

메시에서 mTLS 사용 설정

메시에 mTLS를 설정하려면 백엔드 서비스에 대한 아웃바운드 트래픽과 엔드포인트에 대한 인바운드 트래픽을 보호해야 합니다.

정책 참조 형식

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

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

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

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy

백엔드 서비스에 대한 아웃바운드 트래픽 보호

아웃바운드 트래픽을 보호하려면 먼저 다음을 수행하는 클라이언트 TLS 정책을 만듭니다.

google_cloud_private_spiffe를 clientCertificate의 플러그인으로 사용하여 Envoy가 GKE 관리형 메시 인증서를 클라이언트 ID로 사용하도록 프로그래밍합니다.
google_cloud_private_spiffe를 serverValidationCa의 플러그인으로 사용하여 서버 유효성 검사에 GKE 관리형 메시 인증서를 사용하도록 Envoy를 프로그래밍합니다.

다음으로 클라이언트 TLS 정책을 백엔드 서비스에 연결합니다. 다음 작업이 수행됩니다.

클라이언트 TLS 정책의 인증 정책을 백엔드 서비스의 엔드포인트에 대한 아웃바운드 연결에 적용합니다.
주체 대체 이름(SAN)은 클라이언트가 연결된 서버의 정확한 ID를 어설션하도록 지시합니다.

client-mtls-policy.yaml 파일에 클라이언트 TLS 정책을 만듭니다.

name: "client-mtls-policy"
clientCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
serverValidationCa:
- certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

클라이언트 TLS 정책을 가져옵니다.

gcloud network-security client-tls-policies import client-mtls-policy \
    --source=client-mtls-policy.yaml --location=global

클라이언트 TLS 정책을 백엔드 서비스에 연결합니다. 이렇게 하면 클라이언트에서 이 백엔드 서비스로 전송되는 모든 아웃바운드 요청에 mTLS 인증이 적용됩니다.

gcloud compute backend-services export td-gke-service \
    --global --destination=demo-backend-service.yaml

demo-backend-service.yaml에 다음 줄을 추가합니다.

securitySettings:
  clientTlsPolicy: projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
  subjectAltNames:
    - "spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA"

값을 가져옵니다.

gcloud compute backend-services import td-gke-service \
    --global --source=demo-backend-service.yaml

필요한 경우 다음 명령어를 실행하여 요청 실패 여부를 확인하세요. 클라이언트가 엔드포인트에서 인증서를 예상하지만 엔드포인트가 보안 정책으로 프로그래밍되지 않았으므로 이는 예상된 실패입니다.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

다음과 같은 출력이 표시될 것입니다.

wget: server returned error: HTTP/1.1 503 Service Unavailable

엔드포인트에 대한 인바운드 트래픽 보안

인바운드 트래픽을 보호하려면 먼저 다음을 수행하는 서버 TLS 정책을 만듭니다.

google_cloud_private_spiffe를 serverCertificate의 플러그인으로 사용하여 Envoy가 GKE 관리형 메시 인증서를 서버 ID로 사용하도록 프로그래밍합니다.
google_cloud_private_spiffe를 clientValidationCa의 플러그인으로 사용하여 클라이언트 유효성 검사에 GKE 관리형 메시 인증서를 사용하도록 Envoy를 프로그래밍합니다.

서버 TLS 정책 값을 server-mtls-policy.yaml 파일에 저장합니다.

name: "server-mtls-policy"
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
mtlsPolicy:
  clientValidationCa:
  - certificateProviderInstance:
      pluginInstance: google_cloud_private_spiffe

서버 TLS 정책을 만듭니다.

gcloud network-security server-tls-policies import server-mtls-policy \
    --source=server-mtls-policy.yaml --location=global

엔드포인트 일치자가 포함된 ep_mtls.yaml이라는 파일을 만들고 서버 TLS 정책을 연결합니다.

endpointMatcher:
  metadataLabelMatcher:
    metadataLabelMatchCriteria: MATCH_ALL
    metadataLabels:
    - labelName: app
      labelValue: payments
name: "ep"
serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy
type: SIDECAR_PROXY

엔드포인트 일치자를 가져옵니다.

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

설정 검사

다음 curl 명령어를 실행합니다. 요청이 성공적으로 완료되면 출력에 x-forwarded-client-cert가 표시됩니다. 헤더는 연결이 mTLS 연결인 경우에만 출력됩니다.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

다음과 같은 출력이 표시됩니다.

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: 10.48.0.6
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

x-forwarded-client-cert 헤더는 서버 측 Envoy에 의해 삽입되며 자체 ID(서버)와 소스 클라이언트의 ID를 포함합니다. 클라이언트 ID와 서버 ID가 모두 확인되므로 이는 mTLS 연결의 신호입니다.

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

이 안내에서는 호스트 이름이 service-test, 포트가 8000, HTTP 메서드가 GET인 DEMO_CLIENT_KSA 계정에서 전송된 요청을 허용하는 승인 정책을 만듭니다. 승인 정책을 만들기 전에 승인을 사용하여 액세스 제한의 주의 사항을 읽어보세요.

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

action: ALLOW
name: authz-policy
rules:
- sources:
  - principals:
    - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
  destinations:
  - hosts:
    - service-test
    ports:
    - 8000
    methods:
    - GET

정책을 가져옵니다.

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

ep_mtls.yaml 파일에 다음을 추가하여 엔드포인트 정책이 새 승인 정책을 참조하도록 업데이트합니다.
```
authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
```
이제 엔드포인트 정책은 Envoy 사이드카 프록시가 app:payments 라벨을 포함하는 포드에 대한 인바운드 요청에 mTLS와 승인 정책을 모두 적용하도록 지정합니다.

정책을 가져옵니다.

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

설정 검사

다음 명령어를 실행하여 설정의 유효성을 검사합니다.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
# This is a valid request and will be allowed.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

예상 출력은 다음과 비슷합니다.

GET /get HTTP/1.1
Host: service-test
content-length: 0
x-envoy-internal: true
accept: */*
x-forwarded-for: redacted
x-envoy-expected-rq-timeout-ms: 15000
user-agent: curl/7.35.0
x-forwarded-proto: http
x-request-id: redacted
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA

다음 명령어를 실행하여 승인 정책이 잘못된 요청을 올바르게 거부했는지 테스트합니다.

# Failure case
# Command to execute that tests connectivity to the service service-test.
# This is an invalid request and server will reject because the server
# authorization policy only allows GET requests.
TEST_CMD="wget -q -O - service-test --post-data='' ; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

예상 출력은 다음과 비슷합니다.

<RBAC: access denied HTTP/1.1 403 Forbidden>

인그레스 게이트웨이 보안 설정

이 섹션에서는 사이드카 자동 인젝터로 GKE 클러스터 설정, 인증 기관 만들기, 엔드포인트 정책 만들기를 포함하여 서비스 간 보안 섹션을 완료했다고 가정합니다.

이 섹션에서는 TLS 연결을 종료하고 클러스터의 내부 클라이언트의 요청을 승인하는 Envoy 프록시를 인그레스 게이트웨이로 배포합니다.

인그레스 게이트웨이를 설정하여 TLS를 종료하려면 다음 안내를 따르세요.

클러스터 내부 IP 주소를 사용하여 연결 가능한 Kubernetes 서비스를 배포합니다.
1. 배포는 Kubernetes 서비스로 노출되고 Cloud Service Mesh에 연결되는 독립형 Envoy 프록시로 구성됩니다.
TLS를 종료할 서버 TLS 정책을 만듭니다.
들어오는 요청을 승인하기 위한 승인 정책을 만듭니다.

GKE에 인그레스 게이트웨이 서비스 배포

다음 명령어를 실행하여 GKE에 인그레스 게이트웨이 서비스를 배포합니다.

wget -q -O -  https://storage.googleapis.com/traffic-director/security/ga/gateway_sample_xdsv3.yaml | sed -e s/PROJECT_NUMBER_PLACEHOLDER/PROJNUM/g | sed -e s/NETWORK_PLACEHOLDER/default/g | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > gateway_sample.yaml

kubectl apply -f gateway_sample.yaml

gateway_sample.yaml 파일은 인그레스 게이트웨이 사양입니다. 다음 섹션에서는 사양에 추가된 내용을 설명합니다.

Cloud Service Mesh 사이드카 삽입 사용 중지

gateway_sample.yaml 사양은 Envoy 프록시를 단독 컨테이너로 배포합니다. 이전 단계에서 Envoy는 애플리케이션 컨테이너에 사이드카로 삽입되었습니다. 여러 Envoy에서 요청을 처리하지 않도록 하려면 다음 문을 사용하여 이 Kubernetes 서비스에 사이드카 삽입을 중지하면 됩니다.

sidecar.istio.io/inject: "false"

올바른 볼륨 마운트

gateway_sample.yaml 사양은 볼륨 gke-workload-certificates를 마운트합니다. 이 볼륨은 사이드카 배포에도 사용되지만 cloud.google.com/enableManagedCerts: "true" 주석을 볼 때 사이드카 인젝터에서 자동으로 추가합니다. gke-workload-certificates 볼륨에는 GKE 관리형 SPIFFE 인증서와 설정한 CA 서비스 인스턴스에서 서명한 키가 포함됩니다.

클러스터 내부 IP 주소 설정

ClusterInternal 유형의 서비스를 사용하여 인그레스 게이트웨이를 구성합니다. 이렇게 하면 내부적으로 확인 가능한 mesh-gateway의 DNS 호스트 이름이 생성됩니다. 클라이언트에서 요청을 mesh-gateway:443로 전송하면 Kubernetes는 요청을 즉시 인그레스 게이트웨이 Envoy 배포 포트 8080로 라우팅합니다.

인그레스 게이트웨이에서 TLS 사용 설정

인그레스 게이트웨이에서 TLS를 사용 설정하려면 다음 안내를 따르세요.

server-tls-policy.yaml이라는 파일에 다음 값을 사용하여 TLS 연결을 종료할 서버 TLS 정책 리소스를 만듭니다.

description: tls server policy
name: server-tls-policy
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

서버 TLS 정책을 가져옵니다.

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

새 대상 Gateway를 만들어 td-gke-gateway.yaml 파일에 저장합니다. 이는 서버 TLS 정책을 연결하고 Envoy 프록시 인그레스 게이트웨이에서 수신되는 TLS 트래픽을 종료하도록 구성합니다.
```
name: td-gke-gateway
scope: gateway-proxy
ports:
- 8080
type: OPEN_MESH
serverTLSPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
```

게이트웨이를 가져옵니다.

gcloud network-services gateways import td-gke-gateway \
  --source=td-gke-gateway.yaml \
  --location=global

게이트웨이를 참조하고 모든 요청을 td-gke-service로 라우팅하는 td-gke-route라는 새 HTTPRoute를 만들고 저장합니다.

name: td-gke-route
hostnames:
- mesh-gateway
gateways:
- projects/PROJECT_NUMBER/locations/global/gateways/td-gke-gateway
rules:
- action:
    destinations:
    - serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-gke-service"

HTTPRoute를 가져옵니다.

gcloud network-services httproutes import td-gke-route \
  --source=td-gke-route.yaml \
  --location=global

필요한 경우 다음 조건이 모두 충족되면 요청을 허용하도록 백엔드의 승인 정책을 업데이트합니다.
- DEMO_CLIENT_KSA에서 보낸 요청입니다. (인그레스 게이트웨이 배포에서는 DEMO_CLIENT_KSA 서비스 계정을 사용합니다.)
- 호스트 mesh-gateway 또는 service-test를 사용한 요청
- 포트: 8000
백엔드에 대한 승인 정책을 구성하지 않는 한 이러한 명령어를 실행할 필요가 없습니다. 엔드포인트에 승인 정책이 없거나 승인 정책에 호스트나 소스 주 구성원 일치가 없으면 이 단계 없이 요청이 허용됩니다. 이러한 값을 authz-policy.yaml에 추가합니다.
```
action: ALLOW
name: authz-policy
rules:
- sources:
  - principals:
    - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
  destinations:
  - hosts:
    - service-test
    - mesh-gateway
    ports:
    - 8000
    methods:
    - GET
```

정책을 가져옵니다.

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

인그레스 게이트웨이 배포 검증

debug라는 새 컨테이너를 사용하여 인그레스 게이트웨이에 요청을 보내 배포를 검증합니다.

다음 사양에서 주석 "sidecar.istio.io/inject":"false"는 Cloud Service Mesh 사이드카 인젝터가 사이드카 프록시를 자동으로 삽입하지 못하도록 합니다. 요청 라우팅에서 debug 컨테이너를 지원하는 사이드카는 없습니다. 컨테이너가 라우팅될 수 있도록 인그레스 게이트웨이에 연결되어야 합니다.

사양에는 서버 인증서 유효성 검사를 무시하는 --no-check-certificate 플래그가 포함됩니다. debug 컨테이너에는 인그레스 게이트웨이에서 TLS를 종료하는 데 사용하는 CA 서비스에서 서명한 유효한 인증서에 필요한 인증 기관 유효성 검사 인증서가 없습니다.

프로덕션 환경에서는 CA 서비스 유효성 검사 인증서를 다운로드하여 클라이언트에 마운트하거나 설치하는 것이 좋습니다. 유효성 검사 인증서를 설치한 후 wget 명령어의 --no-check-certificate 옵션을 삭제합니다.

다음 명령어를 실행합니다.

kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"

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

GET / HTTP/1.1
Host: 10.68.7.132
x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
x-envoy-expected-rq-timeout-ms: 15000
x-envoy-internal: true
x-request-id: 5ae429e7-0e18-4bd9-bb79-4e4149cf8fef
x-forwarded-for: 10.64.0.53
x-forwarded-proto: https
content-length: 0
user-agent: Wget

다음 음성 테스트 명령어를 실행합니다.

# Negative test
# Expect this to fail because gateway expects TLS.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - http://mesh-gateway:443/headers; echo"

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

wget: error getting response: Connection reset by peer

다음 음성 테스트 명령어를 실행합니다.

# Negative test.
# AuthorizationPolicy applied on the endpoints expect a GET request. Otherwise
# the request is denied authorization.
kubectl run -i --tty --rm debug --image=busybox --restart=Never  --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }'  -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway --post-data=''; echo"

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

HTTP/1.1 403 Forbidden
wget: server returned error: HTTP/1.1 403 Forbidden

배포 삭제

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

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

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

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

gcloud compute backend-services delete td-gke-service --global --quiet
cloud compute network-endpoint-groups delete service-test-neg --zone ZONE --quiet
gcloud compute firewall-rules delete fw-allow-health-checks --quiet
gcloud compute health-checks delete td-gke-health-check --quiet
gcloud network-services endpoint-policies delete ep \
    --location=global --quiet
gcloud network-security authorization-policies delete authz-gateway-policy \
   --location=global --quiet
gcloud network-security authorization-policies delete 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 서비스 보안은 GKE에서만 지원됩니다. Compute Engine으로는 서비스 보안을 배포할 수 없습니다.

문제 해결

이 섹션에서는 보안 서비스 설정 중에 발생하는 문제를 해결하는 방법을 설명합니다.

연결 실패

upstream connect 오류 또는 disconnect/reset before headers 오류와 함께 연결에 실패하면 Envoy 로그를 검사하세요. 여기서 다음 로그 메시지 중 하나가 표시될 수 있습니다.

gRPC config stream closed: 5, Requested entity was not found

gRPC config stream closed: 2, no credential token is found

Envoy 로그에 이러한 오류가 표시되는 경우 서비스 계정 토큰이 잘못 마운트되었거나, 다른 audience를 사용하거나, 둘 다 사용하고 있는 것일 수 있습니다.

자세한 내용은 구성 문제를 표시하는 Envoy 로그의 오류 메시지를 참조하세요.

생성되지 않은 포드

이 문제를 해결하려면 GKE 포드 자동 배포 문제 해결을 참조하세요.

Envoy가 Cloud Service Mesh로 인증하지 않음

Envoy(envoy-proxy)가 Cloud Service Mesh에 연결하여 xDS 구성을 가져올 때 GKE용 워크로드 아이덴티티 제휴와 Compute Engine VM 기본 서비스 계정을 사용합니다(부트스트랩이 변경되지 않는 한). 인증에 실패하면 Envoy가 준비 상태가 되지 않습니다.

`--workload-identity-certificate-authority flag`로 클러스터를 만들 수 없음

이 오류가 표시되면 Google Cloud CLI의 최신 버전이 실행 중인지 확인합니다.

gcloud components update

포드가 대기 중 상태로 유지

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

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

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

gcloud components update

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

포드가 시작되지 않음

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

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

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

포드 상태를 확인합니다.
```
kubectl get pod -n POD_NAMESPACE POD_NAME
```
다음을 바꿉니다.
- POD_NAMESPACE: 포드의 네임스페이스입니다.
- POD_NAME: 포드의 이름입니다.

포드의 최근 이벤트를 확인합니다.

kubectl describe pod -n POD_NAMESPACE POD_NAME

인증서 프로비저닝에 실패하면 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)

객체가 잘못 구성되었거나 CSR이 거부되어 포드가 시작되지 않는 경우 다음 문제 해결 단계를 참조하세요.

`WorkloadCertificateConfig` 또는 `TrustConfig`가 잘못 구성됨

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

현재 상태를 검색합니다.

WorkloadCertificateConfig의 경우:

kubectl get WorkloadCertificateConfig default -o yaml

TrustConfig의 경우:

kubectl get TrustConfig default -o yaml

상태 출력을 검사합니다. 유효한 객체에는 type: Ready 및 status: "True" 조건이 있습니다.
```
status:
  conditions:
  - lastTransitionTime: "2021-03-04T22:24:11Z"
    message: WorkloadCertificateConfig is ready
    observedGeneration: 1
    reason: ConfigReady
    status: "True"
    type: Ready
```
잘못된 객체의 경우 대신 status: "False"가 표시됩니다. reason 및 message 필드에는 추가 문제 해결 세부정보가 포함되어 있습니다.

CSR이 승인되지 않음

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

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

kubectl get csr \
  --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'

Issued가 아닌 Approved거나 Approved가 아닌 CSR을 선택합니다.
kubectl을 사용하여 선택한 CSR의 세부정보를 가져옵니다.
```
kubectl get csr CSR_NAME -o yaml
```
CSR_NAME을 선택한 CSR의 이름으로 바꿉니다.

유효한 CSR에는 type: Approved 및 status: "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의 문제 해결 정보는 message 및 reason 필드에 표시됩니다.

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

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

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

사용한 키 유형이 애플리케이션에서 지원되는지 확인합니다.

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 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.algorithm이 WorkloadCertificateConfig 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
 ...
```

인증서가 거부됨

피어 애플리케이션이 동일한 트러스트 번들을 사용하여 인증서를 확인하는지 확인합니다.

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

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

gRPC Go Credentials Reloading API를 사용하지 않는 경우 클라이언트 코드가 정기적으로 파일 시스템에서 사용자 인증 정보를 새로고침하는지 확인합니다.
워크로드가 CA와 동일한 트러스트 도메인에 있는지 확인합니다. GKE 메시 인증서는 단일 트러스트 도메인에서 워크로드 간 통신을 지원합니다.

Envoy로 서비스 보안 설정

요구사항

설정 준비

gcloud 명령줄 도구 업데이트

변수 설정

API 사용 설정

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

멀티 클러스터 환경에 배포

Fleet에 클러스터 등록

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

Identity and Access Management 구성

Cloud Service Mesh 설정

클러스터에 Envoy 사이드카 인젝터 설치

테스트 서비스 설정

Cloud Service Mesh 프록시 메타데이터

CA 서비스에서 서명한 메시 인증서 및 키 사용

인바운드 트래픽 가로채기 포트 구성

NEG로 GKE 서비스 구성

NEG 이름 저장

GKE에 클라이언트 애플리케이션 배포

상태 점검, 방화벽 규칙, 백엔드 서비스 리소스 구성

Mesh 및 HTTPRoute 리소스 구성

서비스 간 보안 설정

메시에서 mTLS 사용 설정

정책 참조 형식

백엔드 서비스에 대한 아웃바운드 트래픽 보호

엔드포인트에 대한 인바운드 트래픽 보안

설정 검사

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

설정 검사

인그레스 게이트웨이 보안 설정

GKE에 인그레스 게이트웨이 서비스 배포

Cloud Service Mesh 사이드카 삽입 사용 중지

올바른 볼륨 마운트

클러스터 내부 IP 주소 설정

인그레스 게이트웨이에서 TLS 사용 설정

인그레스 게이트웨이 배포 검증

배포 삭제

제한사항

문제 해결

연결 실패

생성되지 않은 포드

Envoy가 Cloud Service Mesh로 인증하지 않음

--workload-identity-certificate-authority flag로 클러스터를 만들 수 없음

포드가 대기 중 상태로 유지

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

포드가 시작되지 않음

WorkloadCertificateConfig 또는 TrustConfig가 잘못 구성됨

CSR이 승인되지 않음

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

인증서가 거부됨

`gcloud` 명령줄 도구 업데이트

`Mesh` 및 `HTTPRoute` 리소스 구성

`--workload-identity-certificate-authority flag`로 클러스터를 만들 수 없음

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

`WorkloadCertificateConfig` 또는 `TrustConfig`가 잘못 구성됨