이 페이지에서는 Google Cloud의 Identity and Access Management(IAM) 시스템이 작동하는 방식과 이를 사용하여 Google Cloud에서 액세스를 관리하는 방법을 설명합니다.
IAM을 사용하면 특정 Google Cloud 리소스에 대한 세분화된 액세스 권한을 부여하고 다른 리소스에 대한 액세스를 방지할 수 있습니다. IAM은 최소 권한의 원칙을 적용하여 실제로 필요한 것보다 더 많은 권한을 갖지 않도록 합니다.
IAM 작동 방식
IAM을 사용하면 누구(ID)에게 무슨 리소스에 대한 어떤 액세스 권한(역할)이 있는지 정의하여 액세스 제어를 관리할 수 있습니다. 예를 들어 Compute Engine 가상 머신 인스턴스, Google Kubernetes Engine(GKE) 클러스터, Cloud Storage 버킷은 모두 Google Cloud 리소스입니다. 리소스를 구성하는 데 사용하는 조직, 폴더, 프로젝트도 리소스입니다.
IAM에서 리소스 액세스 권한은 최종 사용자에게 직접 부여되지 않습니다. 대신 권한이 역할로 그룹화되고 역할은 인증된 주 구성원에게 부여됩니다. 이전에는 IAM에서 주 구성원을 구성원이라고 했습니다. 일부 API에는 여전히 이 용어가 사용됩니다.
IAM 정책이라고도 하는 허용 정책은 어떤 주 구성원에게 어떤 역할이 부여되는지 정의하고 적용합니다. 각 허용 정책은 리소스에 연결됩니다. 인증된 주 구성원이 리소스에 액세스를 시도하면 IAM은 리소스의 허용 정책을 확인하여 작업 허용 여부를 결정합니다.
다음 다이어그램은 IAM의 권한 관리를 나타낸 것입니다.
이 액세스 관리 모델에는 세 개의 주요 부분이 있습니다.
- 주 구성원. 주 구성원은 리소스에 액세스할 수 있는 ID를 나타냅니다. 주 구성원마다 고유 식별자가 있습니다.
- 역할. 역할이란 권한의 모음입니다. 권한은 리소스에 대해 허용되는 작업을 결정합니다. 주 구성원에게 역할을 부여하면 역할에 포함된 모든 권한을 부여하게 됩니다.
- 정책. 허용 정책은 하나 이상의 주 구성원을 개별 역할에 결합하는 역할 결합 모음입니다. 리소스에 대해 누구(주 구성원)에게 어떠한 액세스 권한(역할)이 있는지 정의하려면 허용 정책을 만들고 리소스에 연결합니다.
예를 들어 앞의 다이어그램에서 허용 정책은 user@example.com과 같은 주 구성원을 App Engine 관리자 역할(roles/appengine.appAdmin)과 같은 역할에 결합합니다. 허용 정책이 프로젝트에 연결되어 있으면 구성원은 프로젝트 내에서 지정된 역할을 갖습니다.
이 페이지의 나머지 부분에서는 이러한 개념을 더 자세히 설명합니다.
주 구성원
IAM에서는 리소스에 액세스할 수 있는 ID를 나타내는 주 구성원에 액세스 권한을 부여합니다. 액세스 관리 컨텍스트에서 주 구성원은 다음 유형 중 하나일 수 있습니다.
- Google 계정
- 서비스 계정
- Google 그룹스
- Google Workspace 계정
- Cloud ID 도메인
allAuthenticatedUsersallUsers- 직원 ID 풀의 제휴 ID 1개 이상
- 워크로드 아이덴티티 풀 풀의 제휴 ID 1개 이상
- Google Kubernetes Engine 포드 집합
각 주 구성원 유형의 식별자 형식에 대한 자세한 내용은 주 구성원 식별자를 참조하세요.
Google 계정
Google 계정은 개발자, 관리자 또는 Google에서 만든 계정을 사용하여 Google Cloud와 상호작용하는 다른 모든 사람을 나타냅니다. gmail.com 이메일 주소 또는 다른 도메인의 이메일 주소를 비롯하여 Google 계정과 연결된 모든 이메일 주소를 주 구성원으로 사용할 수 있습니다. 신규 사용자는 Google 계정 가입 페이지에서 Google 계정에 가입할 수 있습니다.
서비스 계정
서비스 계정은 개별 최종 사용자가 아닌 애플리케이션 또는 컴퓨팅 워크로드에 대한 계정입니다. Google Cloud에서 호스팅되는 코드를 실행할 때는 애플리케이션의 ID로 사용할 서비스 계정을 지정합니다. 애플리케이션의 다양한 논리적 구성요소를 나타내는 데 필요한 만큼 서비스 계정을 생성할 수 있습니다. 서비스 계정을 사용하여 애플리케이션을 인증하는 방법에 관한 자세한 내용은 서비스 계정을 참고하세요.
Google 그룹스
Google 그룹은 여러 Google 계정과 서비스 계정을 모아 이름을 붙인 계정 컬렉션입니다. 모든 Google 그룹에는 그룹과 연결된 고유한 이메일 주소가 있습니다. 모든 Google 그룹의 홈페이지에서 정보를 클릭하면 Google 그룹과 연결된 이메일 주소를 찾을 수 있습니다. Google 그룹스에 대한 자세한 내용은 Google 그룹스 홈페이지를 참조하세요.
Google 그룹스를 사용하면 여러 사용자 컬렉션에 액세스 제어를 편리하게 적용할 수 있습니다. 개별 사용자 또는 서비스 계정에 대해 한 번에 하나씩 액세스 제어 권한을 부여하거나 변경하는 대신 전체 그룹에 대해 액세스 제어 권한을 한꺼번에 부여하고 변경할 수 있습니다. 또한 사용자를 추가하거나 삭제하도록 허용 정책을 업데이트하는 대신 Google 그룹에서 주 구성원을 추가하거나 삭제할 수 있습니다.
Google 그룹스에는 로그인 사용자 인증 정보가 없으므로 Google 그룹스로 ID를 설정하여 리소스에 대한 액세스를 요청할 수 없습니다.
Google Workspace 계정
Google Workspace 계정은 계정에 포함된 모든 Google 계정의 가상 그룹을 나타냅니다. Google Workspace 계정은 example.com과 같은 조직의 인터넷 도메인 이름과 연결됩니다. username@example.com과 같은 새 사용자의 Google 계정을 만들면 Google 계정이 Google Workspace 계정의 가상 그룹에 추가됩니다.
Google 그룹스처럼 Google Workspace 계정을 ID 설정에 사용할 수 없지만 이 도메인을 사용하면 권한을 편리하게 관리할 수 있습니다.
Cloud ID 도메인
Cloud ID 도메인은 조직 내 모든 Google 계정의 가상 그룹을 나타내므로 Google Workspace 계정과 유사합니다. 하지만 Cloud ID 도메인 사용자는 Google Workspace 애플리케이션과 기능에 액세스할 수 없습니다. 자세한 내용은 Cloud ID 정보를 참조하세요.
allAuthenticatedUsers
allAuthenticatedUsers 값은 모든 서비스 계정과 Google 계정으로 인증된 인터넷에서의 모든 사용자를 나타내는 특수 식별자입니다. 이 식별자에는 개인 Gmail 계정과 같이 Google Workspace 계정이나 Cloud ID 도메인에 연결되지 않은 계정이 포함됩니다. 익명 방문자와 같은 인증되지 않은 사용자는 포함되지 않습니다.
외부 ID 공급업체(IdP)에서 관리하는 제휴 ID는 이 주 구성원 유형에 포함되지 않습니다. 직원 ID 제휴 또는 워크로드 아이덴티티 제휴를 사용하는 경우 allAuthenticatedUsers를 사용하지 마세요. 대신 다음 중 하나를 사용합니다.
- 모든 IdP의 사용자를 포함하려면
allUsers를 사용합니다. - 특정 외부 IdP의 사용자를 포함하려면 직원 ID 풀의 모든 ID 또는 워크로드 아이덴티티 풀의 모든 ID에 대한 식별자를 사용합니다.
일부 리소스 유형은 이 주 구성원 유형을 지원하지 않습니다.
allUsers
allUsers 값은 인증 사용자와 미인증 사용자를 포함하여 인터넷 상의 모든 사용자를 나타내는 특수 식별자입니다.
일부 리소스 유형은 이 주 구성원 유형을 지원하지 않습니다.
직원 ID 풀의 제휴 ID
직원 ID 풀의 제휴 ID는 외부 IdP에서 관리하고 직원 ID 제휴를 사용하여 제휴된 사용자 ID입니다. 직원 ID 풀의 특정 ID를 사용하거나 특정 속성을 사용하여 직원 ID 풀의 사용자 ID 그룹을 지정할 수 있습니다. 제휴 ID의 주 구성원 식별자에 관한 자세한 내용은 주 구성원 식별자를 참고하세요.
워크로드 아이덴티티 풀의 제휴 ID
워크로드 아이덴티티 풀의 제휴 ID는 외부 IdP에서 관리하고 워크로드 아이덴티티 제휴를 사용하여 제휴된 워크로드 ID입니다. 워크로드 아이덴티티 풀의 특정 워크로드 ID를 사용하거나 특정 속성을 사용하여 워크로드 아이덴티티 풀의 워크로드 ID 그룹을 지정할 수 있습니다. 제휴 ID의 주 구성원 식별자에 관한 자세한 내용은 주 구성원 식별자를 참고하세요.
GKE 포드
GKE에서 실행되는 워크로드는 GKE용 워크로드 아이덴티티 제휴를 사용하여 Google Cloud 서비스에 액세스합니다. GKE 포드의 주 구성원 식별자에 대한 자세한 내용은 IAM 정책에서 Kubernetes 리소스 참조를 참고하세요.
리소스
사용자가 특정 Google Cloud 리소스에 액세스해야 하면 해당 리소스에 대한 역할을 사용자에게 부여할 수 있습니다. 프로젝트, Compute Engine 인스턴스, Cloud Storage 버킷이 리소스의 예시에 해당됩니다.
일부 서비스는 프로젝트 수준보다 세분화된 IAM 권한 부여를 지원합니다. 예를 들어 특정 Cloud Storage 버킷의 사용자에게 스토리지 관리자 역할(roles/storage.admin)을 부여하거나 특정 Compute Engine 인스턴스의 사용자에게 Compute 인스턴스 관리자 역할(roles/compute.instanceAdmin)을 부여할 수 있습니다.
다른 경우에는 프로젝트 수준에서 IAM 권한을 부여할 수 있습니다. 권한은 프로젝트의 모든 리소스에 상속됩니다. 예를 들어 프로젝트의 모든 Cloud Storage 버킷에 대한 액세스 권한을 부여하려면 각 개별 버킷이 아닌 프로젝트에 대한 액세스 권한을 부여합니다. 또는 프로젝트의 모든 Compute Engine 인스턴스에 대한 액세스 권한을 부여하려면 각 개별 인스턴스가 아닌 프로젝트에 대한 액세스 권한을 부여합니다.
리소스별로 부여할 수 있는 역할에 대한 자세한 내용은 역할 이해와 주어진 역할의 최하위 리소스 열을 참조하세요.
권한
권한은 리소스에 대해 허용되는 작업을 결정합니다. IAM 환경에서 권한은 service.resource.verb 형식으로 표시됩니다(예: pubsub.subscriptions.consume).
권한은 종종 REST API 메서드와 일대일 대응합니다. 다시 말해, 각 Google Cloud 서비스에는 노출하는 REST API 메서드마다 연결된 권한이 있습니다. 해당 메서드의 호출자는 해당 메서드를 호출할 수 있는 권한이 필요합니다. 예를 들어 Pub/Sub를 사용하는 경우 topics.publish() 메서드를 호출하려면 해당 주제에 대한 pubsub.topics.publish 권한이 있어야 합니다.
사용자에게 직접 권한을 부여하지는 않습니다. 대신 적절한 권한이 포함된 역할을 식별한 다음 해당 역할을 사용자에게 부여합니다. 사용 가능한 모든 권한 및 이를 포함하는 역할의 목록은 권한 참조를 참조하세요.
역할
역할이란 권한의 모음입니다. 사용자에게 직접 권한을 부여할 수 없습니다. 대신 역할을 부여합니다. 사용자에게 역할을 부여하면 역할에 포함된 모든 권한이 부여됩니다.
IAM에는 다음과 같은 여러 종류의 역할이 있습니다.
기본 역할: 이전부터 Google Cloud 콘솔에 제공되는 역할로, 소유자, 편집자, 뷰어 역할이 있습니다.
사전 정의된 역할: 기본 역할보다 더욱 세부적으로 액세스 제어를 할 수 있는 역할입니다. 예를 들어 사전 정의된 역할 Pub/Sub 게시자(
roles/pubsub.publisher)는 메시지를 Pub/Sub 주제에 게시할 수 있는 액세스 권한만 부여합니다.커스텀 역할: 사전 정의된 역할로 필요한 사항을 조직에 충족할 수 없는 경우 조직의 필요에 맞게 생성하는 커스텀 역할입니다.
역할에 대한 자세한 내용은 다음 리소스를 참조하세요.
- 사용자에게 역할을 부여하는 방법은 액세스 권한 부여, 변경, 취소를 참조하세요.
- 사용 가능한 IAM 사전 정의된 역할에 대한 자세한 내용은 역할 이해를 참조하세요.
- 커스텀 역할에 대한 자세한 내용은 커스텀 역할 이해와 커스텀 역할 만들기 및 관리를 참조하세요.
허용 정책
인증된 주 구성원이 리소스에 액세스를 시도하면 IAM은 리소스의 허용 정책을 확인하여 작업 허용 여부를 결정합니다.
사용자에게 부여되는 액세스 권한의 유형을 정의하는 여러 구문으로 구성된 허용 정책을 만들어 사용자에게 역할을 부여할 수 있습니다. 허용 정책은 리소스에 연결되며 리소스에 액세스할 때마다 액세스 제어를 적용하는 데 사용됩니다.
허용 정책은 역할 결합 목록으로 구성됩니다. 역할 결합은 주 구성원 목록을 역할에 결합합니다.
role: 주 구성원에게 부여할 역할입니다.role은roles/service.roleName형식으로 지정됩니다. 예를 들어 Cloud Storage는roles/storage.objectAdmin,roles/storage.objectCreator,roles/storage.objectViewer등의 역할을 제공합니다.members: 이 문서의 ID와 관련된 개념 섹션에서 설명한 주 구성원 한 개 이상의 목록입니다. 각 주 구성원 유형은 Google 계정(예:user:), 서비스 계정(serviceAccount:), Google 그룹(group:), Google Workspace 계정 또는 Cloud ID 도메인(domain:)과 같은 프리픽스로 식별됩니다. 다음 예시 코드 스니펫에서는storage.objectAdmin역할이user:ali@example.com,serviceAccount:my-other-app@appspot.gserviceaccount.com,group:admins@example.com,domain:google.com중 적합한 프리픽스를 사용하여 다음 주 구성원에게 부여됩니다.objectViewer역할은user:maria@example.com에 부여됩니다.
다음 코드 스니펫은 허용 정책의 구조를 보여줍니다.
{
"bindings": [
{
"role": "roles/storage.objectAdmin",
"members": [
"user:ali@example.com",
"serviceAccount:my-other-app@appspot.gserviceaccount.com",
"group:admins@example.com",
"domain:google.com"
]
},
{
"role": "roles/storage.objectViewer",
"members": [
"user:maria@example.com"
]
}
]
}
IAM 및 정책 API
IAM은 Google Cloud 리소스에서 허용 정책을 만들고 관리하는 데 사용할 수 있는 일련의 메서드를 제공합니다. 이 메서드는 IAM을 지원하는 서비스에서 노출됩니다. 예를 들어 IAM 메서드는 Resource Manager, Pub/Sub, Cloud Life Sciences API 등에서 노출됩니다.
IAM 메서드는 다음과 같습니다.
setIamPolicy(): 리소스에 허용 정책을 설정합니다.getIamPolicy(): 이전에 설정된 허용 정책을 가져옵니다.testIamPermissions(): 호출자에게 리소스에 대해 지정된 권한이 있는지 여부를 테스트합니다.
IAM을 지원하는 각 서비스의 문서에서 메서드에 관한 API 참조 주제를 찾을 수 있습니다.
리소스 계층 구조
Google Cloud 리소스는 계층적으로 구성됩니다.
- 조직은 계층 구조의 루트 노드입니다.
- 폴더는 조직 또는 다른 폴더의 하위 요소입니다.
- 프로젝트는 조직 또는 폴더의 하위 요소입니다.
- 각 서비스의 리소스는 프로젝트의 하위 요소입니다.
각 리소스는 단 하나의 상위 요소만 가집니다. 자세한 내용은 Resource Manager 리소스 계층 구조를 참조하세요.
다음 다이어그램은 Google Cloud 리소스 계층 구조의 예시입니다.
허용 정책은 조직 수준, 폴더 수준, 프로젝트 수준, 리소스 수준 등 리소스 계층 구조의 모든 수준에서 설정할 수 있습니다. 리소스는 모든 상위 리소스의 허용 정책을 상속합니다. 리소스의 유효 허용 정책은 해당 리소스에 설정된 허용 정책과 계층 구조의 위에서 상속된 허용 정책의 합집합입니다.
정책 상속은 하위 수준으로 전이됩니다. 즉, 리소스는 프로젝트에서 허용 정책을 상속하고, 프로젝트는 폴더에서 허용 정책을 상속하며, 폴더는 조직에서 허용 정책을 상속합니다. 따라서 조직 수준 허용 정책도 리소스 레벨에 적용됩니다.
예를 들어 이전 다이어그램에서 topic_a는 프로젝트 example-prod에 속하는 Pub/Sub 리소스입니다. micah@example.com에게는 example-prod에 대한 편집자 역할을 부여하고 song@example.com에게는 topic_a에 대한 게시자 역할을 부여하면 micah@example.com은 topic_a에 대한 편집자 역할을, song@gmail.com은 게시자 역할을 부여받게 됩니다.
하위 리소스 허용 정책은 상위 리소스 허용 정책을 상속받습니다. 예를 들어 사용자에게 프로젝트의 편집자 역할을 부여하고 동일한 사용자에게 하위 리소스의 뷰어 역할을 부여하는 경우, 사용자는 하위 리소스에 부여된 편집자 역할을 계속 갖게 됩니다. 리소스 계층 구조를 변경하면 정책 상속도 변경됩니다. 예를 들어 프로젝트를 조직으로 이동하면 프로젝트가 조직의 허용 정책에서 상속됩니다.
Google Cloud 서비스의 IAM 지원
IAM을 사용하면 모든 Google Cloud 서비스의 모든 API 메서드에서 API를 요청하는 계정에 리소스를 사용할 수 있는 적절한 권한이 있는지 확인합니다.
Google Cloud 서비스는 세분화된 액세스 제어를 가능케 해주는 사전 정의된 역할을 제공합니다. 예를 들어 Compute Engine은 Compute 인스턴스 관리자 및 Compute 네트워크 관리자와 같은 역할을 제공하고 Cloud Storage는 스토리지 폴더 관리자 및 스토리지 객체 사용자와 같은 역할을 제공합니다.
대부분의 Google Cloud 서비스에는 사전 정의된 역할을 사용할 수 있습니다. 자세한 내용은 사전 정의된 전체 역할 목록을 참조하세요. 권한을 더욱 세분화하여 제어해야 하는 경우에는 커스텀 역할을 만드는 것이 좋습니다.
프로젝트 수준보다 더욱 세밀하게 리소스에 액세스할 수 있는 특정 역할을 사용자에게 부여할 수 있습니다. 예를 들어 사용자에게 특정 Pub/Sub 주제에 대해 구독자 역할을 부여하는 허용 정책을 만들 수 있습니다. 사전 정의된 전체 역할 목록에는 각 역할을 허용하는 가장 낮은 수준 또는 가장 세분화된 리소스 유형이 표시됩니다.
IAM API의 일관성 모델
IAM API는 eventual consistency를 갖게 됩니다. 즉, IAM API로 데이터를 쓴 후 즉시 데이터를 읽으면 읽기 작업에서 이전 버전의 데이터를 반환할 수 있습니다. 또한 변경사항이 액세스 검사에 영향을 주는 데 시간이 걸릴 수 있습니다.
이 일관성 모델은 IAM API의 작동 방식에 영향을 줍니다. 예를 들어 서비스 계정을 만든 다음 다른 요청에서 해당 서비스 계정을 즉시 참조하는 경우 IAM API에서 서비스 계정을 찾을 수 없다고 표시될 수 있습니다. 이는 작업이 eventual consistency를 가지기 때문에 발생합니다. 새 서비스 계정이 읽기 요청에 표시되는 데 다소 시간이 걸릴 수 있습니다.
다음 단계
- 사용 가능한 IAM 역할 목록은 역할 이해를 참조하세요.
- 가장 적합한 사전 정의된 역할을 선택하는 데 도움이 필요하면 사전 정의된 역할 선택을 참조하세요.
- 구체적인 요구사항에 맞는 역할 생성에 관한 자세한 내용은 커스텀 역할 이해를 참조하세요.
- 주 구성원에 IAM 역할을 부여, 변경, 취소하는 방법은 리소스에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.
- 허용 정책을 이해하고 관리하여 보안 구성을 사전에 개선하는 데 도움이 되는 Policy Intelligence 도구를 살펴보세요.
- 애플리케이션 보안을 강화하는 방법은 IAP(Identity-Aware Proxy) 개요를 참조하세요.
직접 사용해 보기
Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.
무료로 시작하기