기본적으로 모든 Google Cloud 프로젝트에는 원래 프로젝트 생성자인 단일 사용자가 존재합니다. 그 외 다른 사용자에게는 프로젝트에 대한 액세스 권한이 없으므로 사용자를 프로젝트 구성원으로 추가할 때까지는 Compute Engine 리소스에 대한 액세스가 특정 리소스로 제한됩니다. 이 페이지에서는 새 사용자를 프로젝트에 추가하는 다양한 방법과 Identity and Access Management(IAM)를 사용하여 Compute Engine 리소스의 액세스 제어를 설정하는 방법을 설명합니다.
Compute Engine 인스턴스에서 실행되는 애플리케이션에 대한 액세스 권한을 제공하는 방법은 승인 확인 방법을 참조하세요.
사용자 액세스 제어 옵션
Compute Engine 리소스를 만들고 관리할 수 있는 권한을 사용자에게 부여하려면 사용자를 팀 구성원으로 프로젝트나 특정 리소스에 추가하고 IAM 역할을 사용하여 권한을 부여합니다.
팀 구성원은 유효한 Google 계정이 있는 개별 사용자, Google 그룹, 서비스 계정 또는 Google Workspace 도메인일 수 있습니다. 팀 구성원을 프로젝트나 리소스에 추가할 때 구성원에게 부여할 역할을 지정합니다. IAM은 세 가지 유형의 역할, 즉 사전 정의된 역할, 기본 역할, 커스텀 역할을 제공합니다.
리소스는 Google Cloud 리소스 계층 구조의 상위 리소스에 적용된 정책을 상속합니다. 리소스의 유효 정책은 해당 리소스에 설정된 정책과 상위 리소스에서 상속된 정책의 합집합입니다.
사전 정의된 Compute Engine 역할
사전 정의된 역할은 관련 권한 집합을 부여합니다. Compute Engine은 다음과 같은 사전 정의된 역할을 제공합니다.
| 역할 칭호 | 기능 | 대상 사용자 |
|---|---|---|
| Compute Engine 이미지 사용자 |
다른 프로젝트의 이미지를 나열하고 사용할 수 있는 권한입니다. 다른 역할과 함께 이 역할을 특정 멤버에 부여하면 해당 멤버가 다른 프로젝트의 이미지를 사용해서 새 리소스를 만들 수 있습니다. 예를 들어 이 역할과 인스턴스 관리자 역할을 부여하면 해당 구성원이 다른 프로젝트의 이미지를 사용하여 VM 인스턴스와 영구 디스크를 만들 수 있습니다. 관리형 인스턴스 그룹을 만들거나 Deployment Manager를 사용하여 VM 인스턴스를 만드는 경우에 다른 프로젝트의 이미지를 사용하려면 먼저 프로젝트의 Google API 서비스 계정에 이 역할을 부여해야 할 수 있습니다. |
|
| Compute Engine 인스턴스 관리자(v1) |
Compute Engine 인스턴스, 인스턴스 그룹, 디스크, 스냅샷, 이미지를 관리할 수 있는 전체 권한을 제공합니다. 모든 Compute Engine 네트워킹 리소스에 대한 읽기 전용 액세스 권한이 부여됩니다. 구성원이 서비스 계정으로 실행되도록 구성된 VM 인스턴스를 관리하는 경우 VM 인스턴스에 서비스 계정을 할당할 수 있도록 |
|
| Compute Engine 관리자 역할 |
모든 Compute Engine 리소스를 관리할 수 있는 전체 권한입니다. 사용자가 서비스 계정으로 실행되도록 구성된 VM 인스턴스를 관리할 경우 |
|
| Compute Engine 네트워크 관리자 |
방화벽 규칙과 SSL 인증서를 제외하고 네트워킹 리소스를 생성, 수정, 삭제할 수 있는 권한입니다. 네트워크 관리자 역할에서는 방화벽 규칙, SSL 인증서, 인스턴스에 대한 읽기 전용 액세스(임시 IP 주소 보기) 권한이 허용되지만 구성원이 인스턴스를 생성, 시작, 중지 또는 삭제할 수 있는 권한은 허용되지 않습니다. |
네트워크 관리자 |
| Compute Engine 보안 관리자 |
방화벽 규칙과 SSL 인증서를 생성, 수정, 삭제할 수 있는 권한입니다. |
보안 관리자 |
| Compute Engine 부하 분산기 관리자베타 |
부하 분산기와 관련 리소스를 생성, 수정, 삭제할 수 있는 권한입니다. |
부하 분산기 관리자 |
| Compute Engine 서비스 계정 사용자 |
서비스 계정을 사용하는 인스턴스를 만들 수 있는 권한과 이미 서비스 계정으로 실행되도록 구성된 인스턴스에서 디스크를 연결하고 메타데이터를 설정할 수 있는 권한입니다. 이 역할에서는 Compute Engine API에 대한 어떠한 권한도 제공하지 않으므로 이 역할 자체만 부여할 수 없습니다. 인스턴스 관리자 역할과 같은 다른 역할과 함께 이 역할을 구성원에게 부여해야 합니다. |
|
| Compute Engine 뷰어 역할 |
Compute Engine 리소스를 가져와 나열할 수 있지만 리소스에 저장된 데이터를 읽을 수 없는 읽기 전용 액세스 권한입니다. 예를 들어, 이 역할이 있는 계정은 모든 디스크를 프로젝트에 목록화할 수 있지만 해당 디스크의 데이터를 전혀 읽을 수 없습니다. |
시스템 관리자 |
| Compute Engine 네트워크 사용자 |
공유 VPC 네트워크를 사용할 수 있는 권한입니다. 특히 호스트 프로젝트에서 리소스를 사용해야 하는 서비스 소유자에게 이 역할을 부여합니다. 이 역할이 부여되면 서비스 소유자는 호스트 프로젝트에 속하는 네트워크와 서브네트워크를 사용할 수 있습니다. 예를 들어 네트워크 사용자는 공유 VPC 호스트 네트워크에 속하는 VM 인스턴스를 만들 수 있지만 호스트 프로젝트에서 새로운 네트워크를 만들거나 삭제할 수 없습니다. |
|
| Compute Engine 네트워크 뷰어 |
모든 네트워킹 리소스에 대한 읽기 전용 액세스 권한입니다. 예를 들어 네트워크 구성을 검사하는 소프트웨어가 있는 경우 이 소프트웨어의 서비스 계정에 네트워크 뷰어 역할을 부여할 수 있습니다. |
|
| Compute Engine 스토리지 관리자베타 |
디스크, 이미지, 스냅샷을 생성, 수정, 삭제할 수 있는 권한을 제공합니다. 예를 들어 회사에 이미지를 관리하는 사람이 있지만 이들에게 프로젝트에 대한 편집자 역할을 주고 싶지 않은 경우, 이들의 계정에 이 역할을 부여합니다. |
|
| Compute Engine 공유 VPC 관리자 |
공유 VPC 호스트 프로젝트를 관리할 수 있는 권한입니다. 특히 호스트 프로젝트를 사용 설정하고 호스트 프로젝트의 네트워크에 서비스 프로젝트를 연결할 수 있습니다. 이 역할은 조직 수준에서만 부여됩니다. |
프로젝트 생성자 |
특정 역할에 따라 권한이 부여되는 API 메서드의 목록을 보려면 Compute Engine IAM 역할 문서를 참조하세요.
사전 정의된 역할 표
다음 표에서 각 Compute Engine 역할의 기능을 모두 비교할 수 있습니다.
| 기능 | 인스턴스 관리자(v1) | 이미지 사용자 | 네트워크 사용자 | 네트워크 뷰어 | 네트워크 관리자 | 보안 관리자 | 스토리지 관리자 | 공유 VPC 관리자 | Compute 관리자 | Compute 뷰어 | 부하 분산기 관리자 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| VM 인스턴스 만들기 또는 삭제 | * | ||||||||||
| VM 인스턴스에 SSH 사용 | * | * | |||||||||
| VM 인스턴스 나열 또는 가져오기 | |||||||||||
| 이미지, 디스크, 스냅샷 만들기 또는 삭제 | |||||||||||
| 이미지 나열 또는 가져오기 | |||||||||||
| 인스턴스 그룹 만들기 또는 삭제 | * | ||||||||||
| 인스턴스 그룹 나열 또는 가져오기 | |||||||||||
| 부하 분산기 만들기 및 관리 | |||||||||||
| VPN 만들기 및 관리 | |||||||||||
| 네트워크/서브네트워크 리소스 보기 | |||||||||||
| 방화벽 규칙 보기 | |||||||||||
| 방화벽 및 SSL 인증서 만들기 및 관리 |
방화벽의 경우 SSL 인증서의 경우 |
||||||||||
| 공유 VPC 호스트 프로젝트 만들기 및 관리 | |||||||||||
| 공유 VPC 호스트 프로젝트에서 네트워크 및 서브네트워크 사용 | |||||||||||
| 네트워크 및 서브네트워크 만들기 및 관리 |
*VM 인스턴스를 서비스 계정으로 실행할 수 있는 경우 서비스 계정 사용자 역할도 부여하세요.
특정 역할에 따라 권한이 부여되는 API 메서드의 목록을 보려면 Compute Engine IAM 역할 문서를 참조하세요.
기본 IAM 역할
기본 IAM 역할은 기존 프로젝트 소유자, 편집자, 뷰어 역할에 직접 매핑됩니다. 일반적으로는 가능하다면 항상 사전 정의된 역할을 사용해야 합니다. 하지만 IAM이 아직 지원되지 않는 일부 경우에는 올바른 권한을 부여하기 위해 기본 역할을 사용해야 할 수 있습니다.
| 역할 칭호 | 권한 |
|---|---|
Owner |
모든 뷰어 및 편집자 권한으로, 청구 설정을 변경하고, 액세스 제어를 관리하고, 프로젝트를 삭제할 수 있는 권한이 포함되어 있습니다. |
Editor |
모든 뷰어 권한으로, 리소스를 생성, 수정, 삭제할 수 있는 권한이 포함되어 있습니다. |
Viewer |
리소스 변경 권한이 없는 모든 리소스에 대한 읽기 전용 권한입니다. |
기본 역할에 대한 자세한 내용은 기본 역할 문서를 참조하세요.
사전 정의된 역할이나 기본 역할이 필요에 맞지 않는 경우에는 커스텀 역할을 만들 수 있습니다.
Compute Engine 리소스에 대한 IAM 정책
VM 인스턴스, 이미지, 디스크와 같은 Compute Engine 리소스에 대한 액세스 권한을 부여하려면 IAM 정책을 이 리소스에 직접 연결하면 됩니다. IAM 정책을 사용하면 프로젝트 수준에서 역할을 관리하는 대신 이러한 리소스에 대한 IAM 역할을 관리할 수 있습니다. 이렇게 하면 공동작업자에게 작업에 필요한 특정 리소스에 대해서만 액세스 권한을 부여하는 최소 권한 원칙을 유연하게 적용할 수 있습니다.
Compute Engine 리소스에 대한 IAM 정책을 사용하면 조직에서는 다음을 수행할 수 있습니다.
- 사용자에게 특정 리소스 하위 집합에 대한 액세스 권한을 부여합니다. 예를 들어 김하나가 프로젝트의 일부 인스턴스를 관리하는 경우 인스턴스 수준의 IAM 정책을 사용하면 김하나에게 이러한 인스턴스에 대한
compute.instanceAdmin.v1역할만 부여할 수 있습니다. 김하나에게 프로젝트에 대해서도 동일한 역할을 부여하면 프로젝트의 모든 인스턴스를 수정할 수 있는 권한이 부여됩니다. - 관리자가 액세스 권한을 부여하도록 허용합니다. 관리자는 강력한 프로젝트 소유자가 아니더라도 인스턴스, 디스크, 이미지에 대한 액세스 권한을 다른 사용자에게 부여할 수 있습니다. 예를 들어 강철수라는 개발자에게 특정 이미지에 대한
compute.storageAdmin역할이 부여된 경우 이 사람은 팀 구성원에게 이 이미지에 대한compute.imageUser역할을 부여하여 팀 구성원과 이미지를 공유할 수 있습니다. Compute Engine 리소스에 대한 IAM 정책이 없으면 강철수는 프로젝트의 IAM 정책을 수정해야 하므로 프로젝트 소유자가 아니라면 이미지를 팀 구성원과 공유할 수 없습니다.
리소스는 상위 리소스의 정책도 상속합니다. 프로젝트 수준에서 정책을 설정하면 모든 하위 리소스로 정책이 상속됩니다. 리소스에 실제로 적용되는 정책은 해당 리소스에 설정된 정책과 계층 구조의 상위 리소스에서 상속된 정책의 합집합입니다. 자세한 내용은 IAM 정책 계층 구조를 참조하세요.
조직 정책
Google Workspace 구성원인 경우 프로젝트가 조직 리소스의 일부일 수 있습니다. 조직 리소스는 Google Workspace 계정과 밀접하게 연결된 Google Cloud 리소스 계층 구조의 최상위 노드입니다. Google Workspace 도메인에 대한 조직 리소스가 생성된 후에는 도메인 구성원이 만든 모든 Google Cloud 프로젝트가 조직 리소스에 속하게 됩니다.
조직은 전체 Google Cloud 리소스 계층 구조에서 허용되는 구성을 제한하는 조직 정책을 구현할 수 있습니다. Compute Engine에서는 다음 정책을 구현할 수 있습니다.
조직 정책을 설정하려면 조직에 대한 orgpolicy.policyAdmin 역할을 부여받아야 합니다.
또한 정책 예외에 따라 프로젝트별 재정의를 설정할 수 있습니다.
조직에 대한 자세한 내용은 조직 문서를 참조하세요.
조직 정책에 대한 자세한 내용은 조직 정책 문서를 참조하세요.
사용자에게 VM 인스턴스에 대한 SSH 액세스 권한 부여
Compute Engine 리소스를 관리할 수 있는 권한을 부여하지 않고 SSH를 사용하여 VM 인스턴스에 연결할 수 있는 권한을 부여하려면 프로젝트에 사용자의 공개 키를 추가하거나 사용자의 공개 키를 특정 인스턴스에 추가합니다. 이 방법을 사용하면 사용자를 프로젝트 구성원으로 추가하지 않고 특정 인스턴스에 대한 액세스 권한을 부여할 수 있습니다.
SSH 및 SSH 키 관리에 대한 자세한 내용은 SSH 키 개요를 참조하세요.
프로젝트 구성원에게 roles/compute.instanceAdmin.v1 역할을 부여할 경우 인스턴스가 서비스 계정으로 실행되도록 설정되지 않은 한, 구성원이 SSH를 사용하여 인스턴스에 자동으로 연결할 수 있습니다. 인스턴스가 서비스 계정으로 실행되도록 설정되면 구성원이 인스턴스에 연결할 수 있도록 roles/iam.serviceAccountUser 역할도 부여해야 합니다.
구성원을 프로젝트 소유자 또는 편집자로 추가하면 프로젝트에 있는 VM 인스턴스에 대한 SSH 액세스 권한도 자동으로 부여됩니다.
VM 인스턴스에서 실행되는 앱의 액세스 제어
인스턴스에서 앱 코드를 실행하고 앱이 다른 Google Cloud API에 인증해야 하는 경우에는 서비스 계정을 만들고 이러한 서비스 계정에 특정 IAM 역할을 부여하면 이 계정이 다른 Google Cloud API에 인증할 수 있습니다. 서비스 계정은 사용자 인증 정보가 포함되지 않는 특수 계정이며 서버 간 상호작용에 적합합니다.
서비스 계정에 대한 자세한 내용은 서비스 계정 문서를 참조하세요.
Compute Engine 워크로드의 관리형 워크로드 아이덴티티
관리형 워크로드 아이덴티티를 사용하여 Certificate Authority Service(CA 서비스)에서 X.509 인증서의 자동 프로비저닝 및 수명 주기 관리를 설정할 수 있습니다. 관리형 워크로드 아이덴티티 인증서는 CA Service에서 발급됩니다. CA 서비스는 비공개 키를 계속 제어하면서 CA 서비스의 배포, 관리, 보안을 간소화하고 자동화하도록 도와주는 가용성과 확장성이 우수한 Google Cloud 서비스입니다.
관리형 워크로드 아이덴티티를 사용하면 Compute Engine에서 관리되는 VM별 mTLS를 활용할 수 있습니다. VM당 mTLS는 VM을 만들 때 발급되는 X.509 인증서를 사용합니다. 이러한 mTLS 인증서는 자동으로 순환되므로 더 이상 인증서 관리에 대해 걱정할 필요가 없습니다.
관리형 워크로드 아이덴티티는 두 Compute Engine VM 간에 상호 인증 및 암호화된 통신을 사용 설정하기 위한 기반을 제공합니다. 예를 들어 관리형 워크로드 아이덴티티를 사용하면 한 VM에서 실행 중인 서비스 A가 mTLS를 사용해 설정된 암호화된 채널을 통해 다른 VM에서 실행 중인 서비스 B와 통신합니다.
관리형 워크로드 아이덴티티 구성에 대한 자세한 내용은 mTLS를 통해 다른 워크로드에 워크로드 인증을 참조하세요.
다음 단계
- 팀 구성원으로 사용자 추가
- IAM 역할 자세히 알아보기
- SSH 키 추가 및 삭제 자세히 알아보기
- 서비스 계정 자세히 알아보기