Connect 게이트웨이 설정
이 가이드는 프로젝트의 사용자와 서비스 계정에서 사용할 Connect 게이트웨이를 설정해야 하는 플랫폼 관리자를 대상으로 합니다. 이 설정을 사용하면 사용자는 다음을 수행할 수 있습니다.
Google Cloud 콘솔을 사용하여 Google Cloud ID로 Google Cloud 외부에서 등록된 클러스터에 로그인합니다.
kubectl을 사용하여 Connect 게이트웨이를 통해 클러스터에 액세스합니다.
이 설정에서는 Google 그룹스의 멤버십이 아닌 개별 ID를 기준으로 사용자와 서비스의 인증만 허용합니다. 추가 그룹 지원을 설정하려면 Google 그룹스를 사용하여 Connect 게이트웨이 설정을 참조하세요.
Connect 게이트웨이에 익숙하지 않으면 기본 개념과 작동 방식에 대한 설명은 개요를 참조하세요.
시작하기 전에
다음 명령줄 도구가 설치되었는지 확인합니다.
- Google Cloud와 상호작용하는 명령줄 도구인 Google Cloud CLI 최신 버전
- Kubernetes 클러스터에 명령어를 실행하기 위한
kubectl.kubectl을 설치해야 하는 경우 이 안내를 따르세요.
Google Cloud와의 상호작용을 위해 Cloud Shell을 셸 환경으로 사용하는 경우 이러한 도구가 자동으로 설치됩니다.
프로젝트에서 사용할 gcloud CLI를 초기화하거나 다음 명령어를 실행하여 gcloud CLI를 승인하고 프로젝트를 기본값으로 설정하세요.
gcloud auth login gcloud config set project PROJECT_ID
설정의 필수 IAM 역할
이 가이드에서는 프로젝트에 roles/owner 권한이 있다고 가정합니다.
프로젝트 소유자가 아니라면 다음 태스크를 수행할 수 있도록 프로젝트 소유자에게 프로젝트에 대한 추가 권한을 부여해 달라고 요청합니다.
API를 사용 설정하려면 서비스 사용량 관리자 역할(
roles/serviceusage.serviceUsageAdmin)에 포함된serviceusage.services.enable권한이 필요합니다. 프로젝트 소유자는 다음과 같이serviceusage.services.enable권한이 사용 설정된 커스텀 역할을 만들거나roles/serviceusage.serviceUsageAdmin을 부여할 수 있습니다.gcloud projects add-iam-policy-binding PROJECT_ID \ --member user:USER_EMAIL_ADDRESS \ --role='roles/serviceusage.serviceUsageAdmin'Connect 게이트웨이를 사용할 수 있도록 사용자 및 서비스 계정에 IAM 권한을 부여하려면 프로젝트 소유자는 다음 명령어를 사용하여 부여할 수 있는 프로젝트 IAM 관리자 역할(
roles/resourcemanager.projectIamAdmin)이 필요합니다.gcloud projects add-iam-policy-binding PROJECT_ID \ --member user:USER_EMAIL_ADDRESS \ --role='roles/resourcemanager.projectIamAdmin'
API 사용 설정
프로젝트에 게이트웨이를 추가하려면 Connect 게이트웨이 API 및 필수 종속 항목 API를 사용 설정합니다. 사용자가 Google Cloud 콘솔을 사용하는 클러스터만 인증하려는 경우에는 connectgateway.googleapis.com을 사용 설정할 필요는 없지만 다른 API를 사용 설정해야 합니다.
gcloud services enable --project=PROJECT_ID \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com
등록된 클러스터 확인
프로젝트 Fleet에 등록된 클러스터만 연결 게이트웨이를 통해 액세스할 수 있습니다. 온프레미스 및 기타 퍼블릭 클라우드에 있는 GKE 클러스터는 생성될 때 자동으로 등록됩니다. 하지만 Google Cloud의 GKE 클러스터와 연결된 클러스터는 별도로 등록해야 합니다. 클러스터를 등록해야 하는 경우 클러스터 등록 가이드의 안내를 따르세요. 게이트웨이를 사용하려면 GKE 클러스터가 Fleet에 등록되어야 합니다.
클러스터가 등록되었는지 확인하려면 다음 명령어를 실행합니다.
gcloud container fleet memberships list
다음 출력 예시와 같이 등록된 모든 클러스터 목록이 표시됩니다.
NAME EXTERNAL_ID
cluster-1 0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2 f0e2ea35-ee0c-11e9-be79-42010a8400c2
사용자에게 IAM 역할 부여
Identity and Access Management(IAM)에서 클러스터에 대한 액세스를 제어합니다. kubectl을 사용하여 클러스터에 액세스하는 데 필요한 IAM 역할은 다음 섹션의 설명대로 Google Cloud 콘솔에서 클러스터에 액세스할 수 있는 역할과 약간 다릅니다.
kubectl을 통해 액세스 역할 부여
사용자가 프로젝트에 roles/owner를 가지고 있지 않은 한 kubectl을 사용하여 Connect 게이트웨이를 통해 클러스터와 상호작용하려면 최소한 사용자 및 서비스 계정에 다음 IAM 역할이 필요합니다.
roles/gkehub.gatewayAdmin: 이 역할을 통해 사용자는 Connect Gateway API에 액세스하여kubectl을 사용해 클러스터를 관리할 수 있습니다.사용자가 연결된 클러스터에 대한 읽기 전용 액세스 권한만 필요한 경우 대신
roles/gkehub.gatewayReader를 부여할 수 있습니다.사용자에게 연결된 클러스터에 대한 읽기/쓰기 액세스 권한이 필요한 경우 대신
roles/gkehub.gatewayEditor를 부여할 수 있습니다.
roles/gkehub.viewer: 이 역할을 통해 사용자는 클러스터kubeconfigs를 검색할 수 있습니다.
이러한 역할에 포함된 권한에 대한 자세한 내용은 IAM 문서의 GKE 허브 역할을 참조하세요.
다음 명령어를 사용하여 이러한 역할을 부여할 수 있습니다.
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkehub.viewer
각 매개변수는 다음과 같습니다.
MEMBER는user|serviceAccount:emailID형식의 사용자나 서비스 계정으로, 예를 들면 다음과 같습니다.user:alice@example.comserviceAccount:test_sa@example-project.iam.gserviceaccount.com
GATEWAY_ROLE는roles/gkehub.gatewayAdmin,roles/gkehub.gatewayReader, 또는roles/gkehub.gatewayEditor입니다.
IAM 권한 및 역할 부여에 대한 자세한 내용은 리소스에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.
Google Cloud 콘솔을 통해 액세스를 위한 역할 부여
Google Cloud 콘솔을 사용하여 Google Cloud 외부의 클러스터와 상호작용하려는 사용자가 클러스터를 보려면 최소한 다음 IAM 역할이 필요합니다.
roles/container.viewer. 이 역할을 통해 사용자는 Google Cloud 콘솔에서 GKE 클러스터 페이지 및 기타 컨테이너 리소스를 볼 수 있습니다. 이 역할에 포함된 권한에 대한 자세한 내용은 IAM 문서의 Kubernetes Engine 역할을 참조하세요.roles/gkehub.viewer. 이 역할을 통해 사용자는 Google Cloud 콘솔에서 Google Cloud 외부에 있는 클러스터를 볼 수 있습니다. 이는kubectl액세스에 필요한 역할 중 하나입니다. 이 역할을 이미 사용자에게 부여했으면 다시 부여할 필요가 없습니다. 이 역할에 포함된 권한에 대한 자세한 내용은 IAM 문서의 GKE 허브 역할을 참조하세요.다음 명령어에서
PROJECT_ID를 Fleet 호스트 프로젝트의 프로젝트 ID로 바꿉니다. 또한MEMBER를user|serviceAccount:emailID형식을 사용하여 사용자의 이메일 주소나 서비스 계정으로 바꿉니다. 예를 들면 다음과 같습니다.user:alice@example.comserviceAccount:test_sa@example-project.iam.gserviceaccount.com
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/container.viewer gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/gkehub.viewer
IAM 역할 부여에 대한 자세한 내용은 IAM 문서의 프로젝트, 폴더, 조직 액세스 관리를 참조하세요.
RBAC 승인 구성
각 클러스터의 Kubernetes API 서버는 Google Cloud 콘솔에서 발생하거나 지정된 사용자와 서비스 계정에서 Connect 게이트웨이를 통해 제공되는 kubectl 명령어에서 발생한 요청을 승인할 수 있어야 합니다. 이렇게 하려면 게이트웨이를 통해 액세스할 수 있게 하려는 각 클러스터에서 역할 기반 액세스 제어(RBAC) 정책을 업데이트해야 합니다. 다음 정책을 추가하거나 업데이트해야 합니다.
- Connect 에이전트가 사용자 대신 Kubernetes API 서버에 요청을 보내도록 승인하는 가장 정책.
- 클러스터에 대한 사용자의 권한을 지정하는 권한 정책.
clusterrole/cluster-admin또는clusterrole/cloud-console-reader와 같은 클러스터 수준 역할이거나role/default/pod-reader와 같은 네임스페이스 수준 역할일 수 있습니다.
(선택사항) cloud-console-reader 역할 만들기
Google Cloud 콘솔에서 클러스터 리소스에 액세스하려는 인증된 사용자는 관련 Kubernetes 권한이 있어야 로그인할 수 있습니다. 이러한 사용자에게 클러스터 관리자와 같은 더 광범위한 권한을 부여하지 않으려면 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스를 볼 수 있는 최소 권한이 포함된 커스텀 RBAC 역할을 만들 수 있습니다. 클러스터에 ClusterRole RBAC 리소스, cloud-console-reader를 만들어서 이 권한 집합을 정의할 수 있습니다.
cloud-console-reader는 사용자에게 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스에 대한 get, list, watch 권한을 부여하여 관련 리소스에 대한 세부정보를 볼 수 있게 합니다.
kubectl
cloud-console-reader ClusterRole을 만들고 이를 클러스터에 적용하려면 다음 명령어를 실행합니다.
cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cloud-console-reader
rules:
- apiGroups: [""]
resources: ["nodes", "persistentvolumes", "pods"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml
그런 다음 다음 섹션의 설명대로 권한 정책을 설정할 때 이 역할을 사용자에게 부여할 수 있습니다.
필수 RBAC 정책 만들기 및 적용
다음에서는 필요한 RBAC 정책을 만들고 적용하는 방법을 보여줍니다. 가장 간단한 방법은 gcloud CLI를 사용하여 적절한 정책을 생성하고 적용하는 것입니다. 또는 원하는 경우 RBAC 정책 파일을 만들고 kubectl을 사용하여 적용할 수 있습니다.
gcloud
gcloud CLI를 사용하여 선택한 클러스터에 정책을 생성하고 적용하려면 다음 명령어를 실행하세요.
gcloud container fleet memberships generate-gateway-rbac \
--membership=MEMBERSHIP_NAME \
--role=ROLE \
--users=USERS \
--project=PROJECT_ID \
--kubeconfig=KUBECONFIG_PATH \
--context=KUBECONFIG_CONTEXT \
--apply
다음을 바꿉니다.
- MEMBERSHIP_NAME: 이 Fleet에서 클러스터를 고유하게 나타내는 데 사용되는 이름입니다. Fleet 멤버십 상태 가져오기에서 클러스터의 멤버십 이름을 확인하는 방법을 확인할 수 있습니다.
- ROLE: 클러스터의 사용자에게 부여할 Kubernetes 역할입니다(예:
clusterrole/cluster-adminclusterrole/cloud-console-reader또는role/mynamespace/namespace-reader). 명령어를 실행하기 전에 이미 이 역할이 있어야 합니다. - USERS: 권한을 부여할 사용자(사용자 계정 또는 서비스 계정)의 이메일 주소이며 쉼표로 구분된 목록으로 표시됩니다. 예를 들면
--users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com입니다. - PROJECT_ID: 클러스터가 등록된 프로젝트 ID입니다.
- KUBECONFIG_PATH: 클러스터 항목이 포함된 kubeconfig가 저장되는 로컬 파일 경로입니다. 대부분의 경우
$HOME/.kube/config입니다. KUBECONFIG_CONTEXT: kubeconfig 파일에 표시되는 클러스터의 클러스터 컨텍스트입니다.
kubectl config current-context를 실행하여 명령줄에서 현재 컨텍스트를 가져올 수 있습니다. 현재 컨텍스트 사용 여부와 관계없이 다음 명령어를 실행하여 클러스터에 액세스할 수 있는지 확인합니다.kubectl get namespaces \ --kubeconfig=KUBECONFIG_PATH \ --context=KUBECONFIG_CONTEXT
gcloud container fleet memberships generate-gateway-rbac을 실행하면 출력 끝에 다음이 표시됩니다.
connectgateway_example-project-12345_global_example-membership-name
Connect 게이트웨이를 통해 클러스터에 액세스하는 데 사용되는 컨텍스트입니다.
generate-gateway-rbac 명령어에 대한 자세한 내용은 gcloud CLI 참조 가이드를 참조하세요.
이 명령어를 실행할 때 오류(예: ERROR: (gcloud.container.hub.memberships)
Invalid choice: 'generate-gateway-rbac')가 표시되면 업데이트 가이드에 따라 Google Cloud CLI를 업데이트합니다.
kubectl
다음 예시에서는 사용자(foo@example.com)와 서비스 계정(test@example-project.iam.gserviceaccount.com)에 적절한 정책을 만들어 클러스터에 대한 cluster-admin 권한을 모두 부여하고 정책 파일을 /tmp/gateway-rbac.yaml로 저장하는 방법을 보여줍니다. 그러면 정책이 현재 컨텍스트와 연결된 클러스터에 적용됩니다.
cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: gateway-impersonate
rules:
- apiGroups:
- ""
resourceNames:
- foo@example.com
- test@example-project.iam.gserviceaccount.com
resources:
- users
verbs:
- impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: gateway-impersonate
roleRef:
kind: ClusterRole
name: gateway-impersonate
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: connect-agent-sa
namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: gateway-cluster-admin
subjects:
- kind: User
name: foo@example.com
- kind: User
name: test@example-project.iam.gserviceaccount.com
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/gateway-rbac.yaml
RBAC 권한 지정에 대한 자세한 내용은 RBAC 승인 사용을 참조하세요.
VPC 서비스 제어 지원
VPC 서비스 제어는 ID 및 액세스 관리(IAM)과 별개로 Google Cloud 서비스의 보안을 더욱 강화합니다. IAM은 세분화된 ID 기반 액세스 제어를 지원하지만 VPC 서비스 제어는 경계 간 데이터 이그레스 제어를 포함한 보다 광범위한 컨텍스트 기반 경계 보안을 지원합니다. 예를 들어 특정 프로젝트만 BigQuery 데이터에 액세스할 수 있도록 지정할 수 있습니다. VPC 서비스 제어를 실행하여 데이터를 보호하는 방식은 VPC 서비스 제어 개요에서 확인할 수 있습니다.
지정된 서비스 경계 내에서 게이트웨이를 사용하는 데 필요한 API에 액세스할 수 있게 되면 VPC 서비스 제어를 Connect 게이트웨이와 함께 사용하여 추가 데이터 보안을 사용할 수 있습니다.
다음 단계
- Connect 게이트웨이를 사용하여 명령줄에서 클러스터에 연결하는 방법 알아보기
- Cloud Build와 통합 튜토리얼에서 DevOps 자동화의 일부로 Connect 게이트웨이를 사용하는 방법의 예시 참조하기