Google Cloud의 액세스 문제 해결 도구 사용 사례

Last reviewed 2022-09-29 UTC

이 문서에서는 Google Cloud 도구를 사용해서 Google Cloud 리소스 액세스와 관련된 사용 사례의 문제 해결 방법을 설명합니다. 애플리케이션에 대한 최종 사용자 액세스 문제 해결 방법은 이 문서에서 설명하지 않습니다. 이 문서에서는 사용자가 Google Cloud의 정책 및 액세스 문제 해결에 익숙하다고 가정합니다. 문제 해결 정책 및 액세스 문제 문서에서는 Google Cloud에서 제공되는 문제 해결 도구 및 액세스 정책을 강제 적용할 수 있는 Google Cloud 서비스에 대해 설명합니다.

문제 해결을 위한 접근법

액세스 관련 문제를 해결하는 첫 번째 단계는 문제 해결 방법을 결정하는 것입니다. 다음 다이어그램에서는 액세스 문제를 해결하는 접근 방식 하나의 플로차트를 제공합니다. 이 플로차트는 사용자에게 문제 해결 단계를 완료할 수 있는 적절한 권한이 있거나 사용자가 필요한 권한이 있는 다른 사용자와 함께 작업할 수 있다고 가정합니다.

액세스 문제 해결을 위한 한 가지 접근법을 보여주는 흐름도

위의 다이어그램은 다음 단계를 간략하게 설명하고 있습니다.

Google Cloud Console 및 Cloud Shell에서 사용자 액세스 권한을 확인합니다. 모든 액세스가 거부되었다면 감사 로그에서 오류 심각도 항목을 확인합니다.
1. 오류 심각도 항목이 있는 경우 필요한 권한을 확인합니다.
  1. 액세스 문제를 해결할 권한을 부여할 수 있으면 해당 문제를 해결하세요.
  2. 액세스 문제를 해결할 수 없는 경우 Cloud Customer Care에 문의합니다.
2. 오류 심각도 항목이 없으면 Customer Care에 문의하세요.
액세스 문제가 없으면 네트워크 문제를 확인합니다. 네트워크 문제가 발견되면 해당 문제를 해결합니다.
네트워크 문제가 없다면 할당량 설정을 확인합니다. 할당량 설정에 문제가 발견되면 프로세스를 따라 할당량을 늘린 다음 문제를 해결하세요.
할당량 설정 문제가 없으면 감사 로그에서 오류 심각도 항목을 확인합니다.
1. 오류 심각도 항목이 있는 경우 필요한 권한을 확인합니다.
  1. 액세스 문제를 해결할 권한을 부여할 수 있으면 해당 문제를 해결하세요.
  2. 액세스 문제를 해결할 수 없는 경우 Customer Care에 문의하세요.
2. 오류 심각도 항목이 없으면 Customer Care에 문의하세요.

다음 섹션에서는 각 문제 해결 단계를 완료하는 방법을 자세히 설명합니다.

사용자 액세스 권한 확인

사용자 액세스가 Google Cloud 콘솔 및 Google Cloud CLI 모두에서 거부되는지 확인합니다.

문제가 발생한 사용자로서 Google Cloud 콘솔에 로그인합니다.
리소스에 액세스해 봅니다. 예를 들어 사용자가 VM을 시작할 수 없다고 보고한 경우 VM을 시작해 보세요.
Google Cloud 콘솔에서 Cloud Shell을 열고 사용자가 로그인된 세션에서 다음 gcloud CLI 명령어를 실행합니다. 이 명령어는 사용자가 올바른 ID에 로그인되어 있고 gcloud CLI를 사용해서 리소스에 액세스할 수 있는지 확인합니다.
```
gcloud auth list
```
출력은 사용자가 로그인한 계정을 반환합니다.
앞의 명령어가 올바른 ID를 반환했는지 확인하세요.
- 이전 명령어가 잘못된 ID를 반환할 경우 사용자에게 올바른 ID로 로그인하도록 요청합니다. 그런 후 올바른 ID를 사용할 때에도 여전히 액세스 문제가 있는지 확인합니다.
- 앞의 명령어가 올바른 ID를 반환하였고 permission denied 메시지를 받았다면 사용자가 완료할 작업에 gcloud CLI 명령어를 실행합니다. 거부에 대한 상세 내용을 보려면 --log-http 및 --verbosity=debug 플래그를 추가하세요.
권한 관련 문제가 확인되면 필수 권한 확인으로 건너뛰세요.

네트워크 문제 확인

VPC 서비스 제어 문제 해결 안내에 따라 네트워크 문제를 확인합니다. VPC 서비스 제어 거부 오류 메시지가 표시되면 해당 문제를 해결합니다.
연결 테스트를 사용하여 소스에서 대상까지 네트워크 경로를 확인합니다. 동일하거나 피어링된 네트워크에서 VM 인스턴스 두 개 간의 연결을 테스트하는 방법에 대한 자세한 내용은 VPC 네트워크 내에서 테스트를 참조하세요.
액세스 경로에 영향을 줄 수 있는 섀도 처리된 방화벽 규칙이나 거부 규칙이 있다면 표시하도록 방화벽 통계를 사용하여 방화벽 구성을 확인하세요.

할당량 설정 확인

네트워크 관련 문제를 찾을 수 없는 경우 할당량 설정을 확인합니다. 할당량 관련 문제가 있다면 정의된 프로세스에 따라 필요 시 할당량을 늘립니다.

감사 로그 확인

로그 탐색기를 사용하여 감사 로그 파일을 확인합니다. 로그 탐색기는 로그 항목의 심각도에 대한 요약 정보를 제공합니다. API 호출이 실패하면 오류 로그 심각도가 기록됩니다. 예를 들어 사용자가 Cloud Storage 버킷을 만들려고 시도할 때 storage.buckets.create 호출 권한이 없으면 오류가 기록됩니다.

로그 항목 요약에서는 다음과 같은 세부정보를 확인할 수 있습니다.
- 대상 리소스 이름
- 주 구성원(리소스에 액세스하려고 하는 사용자)
- 주 구성원이 실행하려고 한 API 호출

필수 권한 확인

주 구성원에게 필요한 권한이 없는 이유를 디버깅하려면 정책 문제 해결 도구를 사용합니다.

확인 결과 액세스 권한이 부여되지 않았다고 나타난 경우 Policy Troubleshooter를 사용하여 권한이 포함되는 역할을 검토하세요.
Policy Analyzer를 사용하면 다른 주체가 주 구성원이 액세스할 수 없는 리소스에 액세스할 수 있는지 확인할 수 있습니다.
적절한 역할 바인딩이 있는 Google 그룹에 주 구성원 ID를 추가합니다.

Customer Care에 문의

위의 문제 해결 섹션을 완료했지만 문제를 해결할 수 없는 경우 Customer Care에 문의하여 도움을 받으시기 바랍니다. 문제 해결 가이드 섹션의 Customer Care에 에스컬레이션에 설명된 대로 최대한 많은 정보를 제공하세요.

문제 해결을 위한 사용 사례 예시

이 섹션에서는 이전의 문제 해결 단계를 사용하여 구체적인 사용 사례 문제를 해결하는 방법을 중점적으로 설명합니다. 모든 사용 사례에서는 Google Cloud의 정책 및 액세스 문제 해결에 설명된 문제 해결 도구를 사용할 수 있는 적절한 권한이 있어야 합니다.

다음 사용 사례에서는 사용자가 사용자 액세스 관리를 위해 Google 그룹스를 사용한다고 가정합니다. 권한 부여를 위해 Google 그룹스를 사용하면 액세스 권한을 대규모로 관리할 수 있습니다. Google 그룹의 각 구성원은 해당 그룹에 부여된 Identity and Access Management(IAM) 역할을 상속합니다. 이러한 상속 덕분에 개별 사용자에게 IAM 역할을 부여하는 대신 그룹 멤버십을 사용해서 사용자의 역할을 관리할 수 있습니다.

역할 위임자가 Compute 관리자 역할에 대한 개발자 액세스 문제 해결

나는 역할 위임자로서 특정 개발자에게 특정 역할을 부여할 수 없는 이유를 알고 싶습니다. 나는 신규 개발자가 팀에 들어오면 Compute 관리자 역할을 정기적으로 부여하고 있습니다. 그런데 오늘 Compute 인스턴스 관리자 역할을 부여하려고 했지만 거부되었습니다.

흐름도에 따라 사용자 액세스를 확인하고 감사 로그를 확인하면 권한 문제인지 파악할 수 있습니다.

역할을 부여할 수 있으려면 resourcemanager.projects.setIamPolicy 권한이 필요합니다. 이 권한은 다음 역할의 일부로 부여될 수 있습니다.

조직 관리자 역할(roles/resourcemanager.organizationAdmin)
폴더 IAM 관리자 역할(roles/resourcemanager.folderIamAdmin)
프로젝트 IAM 관리자 역할(roles/resourcemanager.projectIamAdmin)

역할 위임자에게 resourcemanager.projects.setIamPolicy 권한이 할당되었는지 확인하려면 정책 문제 해결 도구를 사용합니다. 권한이 더 이상 할당되지 않으면 다음을 확인합니다.

정책이 취소되었을 수 있는 IAM 권장사항이 적용되었는지 확인합니다.
마지막으로 역할을 부여할 수 있었던 시간을 알고 있으면 해당 시점과 현재 사이의 로그를 확인하여 적용된 정책이 변경되었을 수 있는 setIam 호출이 있었는지 확인합니다.
Policy Analyzer를 사용하여 resourcemanager.projects.setIamPolicy가 있는 주 구성원을 확인하세요. Policy Analyzer를 사용하면 역할 위임자가 그룹에서 삭제되었는지 알아볼 수 있습니다.

클라우드 관리자가 개발자의 BigQuery 액세스 문제 해결

나는 클라우드 관리자로서 개발자 중 한 명이 더 이상 BigQuery 데이터 세트에 쿼리를 실행할 수 없는 이유를 알고 싶습니다.

이 사용 사례의 문제를 해결하려면 먼저 사용자 액세스를 확인하고 액세스와 관련된 문제가 있으면 해결하도록 합니다. 그런 다음 네트워크 문제를 확인합니다. 이 예시에서는 ID 또는 네트워크 문제 없음을 확인했지만 권한 문제가 있다고 가정합니다.

권한 문제를 해결하려면 먼저 팀 구성원 권한을 확인합니다. 문제를 찾을 수 없으면 로그에 다른 문제가 있는지 확인합니다. 로그에서 문제를 찾을 수 없으면 고객 관리에 도움을 요청할 수 있습니다.

팀 구성원 권한 확인

팀 구성원 권한을 확인하려면 개발자에게 마지막으로 쿼리를 성공적으로 실행한 날짜를 몰어보세요. 그런 다음 개발자팀의 누구라도 이전에 쿼리를 실행할 수 있었고 그 사람이 여전히 쿼리를 성공적으로 실행할 수 있는지 확인합니다. 쿼리를 실행할 수 있는 팀 구성원이 없다면 로그 확인 섹션으로 이동하세요.

팀원이 쿼리를 계속 실행할 수 있으면 다음 단계별 안내를 완료하세요.

두 개발자 모두에게 부여된 IAM 권한을 확인하고 권한이 다른지 확인합니다. 권한을 검토할 때 다음을 확인하세요.
권한이 다르다면 다음의 로그 확인 섹션으로 진행하세요. 권한이 다른 경우 다음 단계별 안내를 완료하세요.
1. 두 팀 구성원 모두가 동일한 Google 그룹에 있는지 확인합니다.
  - 동일한 Google 그룹에 있지 않은 경우 동일한 그룹에 있어야 하는지 확인합니다.
  - 이전에 동일한 Google 그룹에 있었다면 그룹 관리자에게 문의하여 변경 이유를 확인합니다.
권한 문제를 해결한 후 개발자가 쿼리를 실행할 수 있는지 알아봅니다.
- 개발자가 쿼리를 실행할 수 있으면 해당 문제를 해결합니다.
- 개발자가 쿼리를 실행할 수 없으면 다음의 로그 확인 섹션으로 이동합니다.

로그 확인

쿼리를 완료할 수 있는 팀 구성원이 없거나 권한 문제를 해결해도 문제가 해결되지 않으면 로그를 확인하여 개발자가 쿼리를 마지막으로 완료한 이후 무엇이 변경되었는지 알아볼 수 있습니다.

마지막으로 성공한 태스크 로그를 볼 수 있는 위치를 확인합니다. 이 예시에서는 로그를 BigQuery로 내보냅니다.
BigQuery에서 내보낸 로그에 따라 쿼리를 실행합니다.
1. 개발자가 성공한 결과를 확인할 수 있도록 마지막으로 액세스한 날짜가 포함된 쿼리 하나를 실행하세요.
2. 요청이 실패한 시간에 대해서 동일한 쿼리를 실행합니다.
로그에 파악 가능한 문제가 있으면 Policy Troubleshooter 및Policy Analyzer을 사용하여 필수 권한 확인 섹션에 설명된 방법을 참조하여 문제를 해결하세요.
그래도 문제를 해결할 수 없으면 Customer Care에 문의하세요.

개발자에게 GKE에 대한 권한 필요

개발자로서 나에게 액세스 권한이 있는 Google Kubernetes Engine(GKE)에서 포드를 시작, 삭제 또는 배포를 생성할 수 없는 이유를 알고 싶습니다. kubectl 명령줄 도구를 사용하여 호출할 때 내가 어떤 주 구성원인지 또는 나에게 어떤 권한이 있는지 잘 모르겠습니다.

개발자가 포드를 시작, 삭제, 업데이트하거나 GKE 클러스터에서 배포를 만들 수 있는 IAM 역할은 Google Kubernetes Engine 개발자 역할(roles/container.developer)입니다. 이 역할은 GKE 클러스터가 상주하는 프로젝트에서 부여되어야 합니다.

이 사용 사례의 문제를 해결하려면 먼저 사용자 액세스를 확인하고 액세스와 관련된 문제가 있으면 해결하도록 합니다. ID의 유효성을 검증한 후 kubectl 도구가 올바른 클러스터를 가리키도록 구성되었는지 확인하세요. kubectl 도구에서 사용되는 ID가 올바른지, kubectl 도구가 올바른 클러스터를 가리키는지 확인하는 방법에 대한 상세 설명은 클러스터 액세스 구성(kubectl)에서 확인하세요. 이 예시에서는 네트워크 문제나 할당량 관련 문제는 없지만 권한 문제가 있다고 가정하고 있습니다.

권한 문제 해결을 시작하려면 감사 로그를 확인하여 개발자가 마지막으로 성공한 작업과 문제가 처음 보고된 시간 사이에 변경된 사항이 있는지 확인합니다.

이전에 개발자에게 액세스 권한이 있었으면 동일한 작업을 수행할 수 있는 권한이 있는 팀 구성원이 계속 작업을 완료할 수 있는지 확인합니다. 팀 구성원에게 액세스 권한이 있으면 정책 분석기를 사용하여 팀 구성원에게 어떤 액세스 권한이 있는지 확인할 수 있습니다. 권장사항을 따르는 경우 두 개발자 모두에게 동일한 그룹 멤버십과 권한이 있어야 합니다.
1. 사용자 권한이 동일하고 두 개발자 모두 리소스에 대해 작업을 수행할 수 없는 경우에는 액세스에 영향을 줄 수 있는 IAM 권장사항이 적용되었는지 확인합니다.
2. 사용자 권한이 다르면 차이가 발생한 이유를 조사합니다.
  1. 감사 로그에서 개발자가 마지막으로 태스크를 성공적으로 완료할 수 있었던 시간을 확인합니다. 로그를 가장 최근에 시도한 시점과 작업을 완료하지 못한 시점을 비교하세요.
  2. IAM 권장사항을 확인하고 모든 권장사항을 적용합니다.
확인할 다른 팀 구성원이 없는 경우 필수 권한 확인에 설명된 것처럼 Policy Troubleshooter 및 Policy Analyzer를 사용하세요. 자세한 내용은 다음 리소스를 참조하세요.
그래도 문제를 해결할 수 없으면 Customer Care에 문의하세요.

보안 관리자가 개발자 액세스 문제 해결

나는 보안 관리자로서 개발자가 어떤 작업을 수행할 수 없는 이유를 알고 싶습니다. 역할이 사용자에게 필요한 것보다 더 많은 액세스 권한을 제공하지 않도록 하려면 최적의 역할과 그 역할에 할당되는 위치는 무엇인가요?

이 시나리오에서는 개발자가 다음을 수행할 수 있어야 합니다.

Cloud Storage 버킷에 객체 업로드. 개발자는 버킷의 기존 객체를 보거나 삭제하거나 덮어쓸 수 없어야 합니다.
개발 프로젝트에서 인스턴스 시작하기

개발자가 수행해야 하는 태스크 수행을 위해 필요한 권한이 무엇인지 확인하려면 정책 문제 해결 도구 및 IAM 역할 이해 참조 페이지를 사용합니다. 이 예시에서는 개발자에게 다음 권한이 포함된 역할을 부여해야 합니다.

개발자가 인스턴스를 중지하고 시작하게 하려면 부여할 역할: compute.instances.start 및 compute.instances.stop
개발자가 Cloud Storage 버킷에 객체를 업로드할 수 있게 하려면 부여할 역할: storage.objects.create

다음 역할에는 위의 권한이 포함되어 있으며 최소 권한의 원칙을 준수합니다.

개발자가 객체를 업로드할 수 있는 버킷의 버킷 수준에서 스토리지 객체 생성자 역할(roles/storage.objectCreator) 부여
개발자가 할당한 프로젝트의 프로젝트 수준 또는 개발자가 다시 시작해야 하는 인스턴스 수준에서 Compute 인스턴스 관리자 역할(roles/compute.instanceAdmin) 부여

일반적으로 인스턴스를 관리하려면 디스크 추가와 같은 작업이 필요할 수도 있습니다. 이 경우 roles/compute.instanceAdmin 역할은 최소 권한의 원칙을 준수하면서 필요한 권한을 부여하는 적절한 방법이 될 수 있습니다.

애플리케이션이 Cloud Storage에 쓸 수 없는 이유에 대한 클라우드 관리자의 문제 해결

나는 클라우드 관리자로서 GKE에서 실행되는 애플리케이션이 더 이상 Cloud Storage에 쓸 수 없는 이유를 알고 싶습니다.

이 시나리오에서는 GKE에서 실행 중인 애플리케이션을 다음과 같이 구성해야 합니다.

지정된 버킷에서 애플리케이션이 객체를 추가, 업데이트, 삭제할 수 있음
애플리케이션이 조직의 다른 버킷에 액세스할 수 없음

다음 문제 해결 방법에서는 워크로드 아이덴티티를 사용하는 것이 좋습니다. 워크로드 아이덴티티를 사용하면 Kubernetes 서비스 계정을 Google 서비스 계정 역할을 하도록 구성할 수 있습니다. Kubernetes 서비스 계정으로 실행되는 포드는 Google Cloud API에 액세스할 때 Google 서비스 계정으로 자동 인증합니다.

이 예시에서는 클러스터의 워크로드 아이덴티티에 사용 중인 Google 서비스 계정에 적절한 권한을 부여했는지 검증합니다. 애플리케이션 태스크를 완료하는 데 필요한 권한을 이해하려면 정책 문제 해결 도구와 IAM 이해 역할 참조 페이지를 사용합니다. 권한을 구성하고 확인하려면 다음을 수행합니다.

워크로드 아이덴티티를 사용 중인 Google 서비스 계정에 다음 권한을 할당합니다.
1. 애플리케이션이 객체 나열, 생성, 보기 및 삭제를 포함하여 객체를 완전히 제어할 수 있는 버킷에서 스토리지 객체 관리자 역할(roles/storage.objectAdmin)을 부여합니다.
2. Google 서비스 계정을 가장하도록 Kubernetes 서비스 계정을 구성하려면 IAM 정책 바인딩을 설정합니다.
```
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]" \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
  다음 값을 바꿉니다.
  - PROJECT_ID: 프로젝트 ID입니다.
  - KSA_NAME: 요청을 수행하는 Kubernetes 서비스 계정입니다.
  - KUBERNETES_NAMESPACE: Kubernetes 서비스 계정이 정의된 Kubernetes 네임스페이스입니다.
  - GSA_NAME: Google 서비스 계정입니다.
프로젝트에 대한 iam.serviceAccounts.setIamPolicy 권한을 설정하세요.
- Kubernetes 서비스 계정에 다음 주석을 추가합니다.
```
iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID
```
Google 서비스 계정에 올바른 권한이 있고 워크로드 아이덴티티가 올바르게 구성되어 있는지 확인합니다.
1. 애플리케이션이 객체를 완전히 제어할 수 있는 버킷에서 버킷의 IAM 정책을 열람하고 Google 서비스 계정에 roles/storage.objectAdmin 역할이 있는지 확인하세요.
2. 권한이 올바르지 않으면 정책을 수정하여 Google 서비스 계정에 필요한 권한을 부여하세요.
Kubernetes 서비스 계정에 바인딩이 있는지 검증하여 워크로드 아이덴티티가 올바르게 구성되었는지 확인합니다.
```
gcloud iam service-accounts get-iam-policy \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
출력은 다음과 같이 표시됩니다.
```
- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser
```
바인딩이 잘못된 경우 이전 단계를 반복하여 서비스 계정에 권한을 할당합니다.

다음 단계

Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기