
시작하기 전에
- 실습에서는 정해진 기간 동안 Google Cloud 프로젝트와 리소스를 만듭니다.
- 실습에는 시간 제한이 있으며 일시중지 기능이 없습니다. 실습을 종료하면 처음부터 다시 시작해야 합니다.
- 화면 왼쪽 상단에서 실습 시작을 클릭하여 시작합니다.
Initialize Google Cloud SDK
/ 10
Create an instance with name as lab-1 in Project 1
/ 5
Update the default zone
/ 5
Create a configuration for Username 2 and name it as user2
/ 10
Restricting Username 2 to roles/viewer in Project 2
/ 5
Create a new role with permissions for the devops team
/ 10
Check binding to roles/iam.serviceAccountUser
/ 5
Bound Username 2 to devops role
/ 10
Create an instance with name as lab-2 in Project 2
/ 5
Check the created service account
/ 5
Check the binding for the service account to roles/iam.serviceAccountUser
/ 10
Check the binding for the service account to roles/compute.instanceAdmin
/ 10
Check lab-3 has the service account attached
/ 10
클라우드 전문가로서 클라우드 환경을 설정할 때 고려해야 할 가장 기본적인 사항 중 하나는 최소 권한의 원칙에 따라 리소스에 대한 액세스를 구성하는 방법입니다. 몇 가지 주요 질문은 다음과 같습니다.
이 실습에서는 Google Cloud 내의 Identity and Access Management(IAM)의 기본사항을 살펴봅니다. 클라우드 리소스에 대한 액세스를 전략적으로 구성하여 최소 권한의 원칙을 준수하는 방법을 알아봅니다. 명령줄 도구를 사용하여 사용자 권한을 관리하고, 필요한 액세스 권한만 부여하고, 애플리케이션 및 서비스에 대한 안전한 인증 메커니즘을 설정하는 데 중점을 둡니다.
Azure IAM에 익숙하다면 이 실습을 통해 해당 개념을 Google Cloud 환경에 적용해 볼 수 있습니다. 역할 및 권한에 대한 Google Cloud IAM의 고유한 접근방식을 살펴봅니다. 이 실습에서는 gcloud 명령줄 도구를 설치하고 구성하며 여러 구성과 서비스 계정을 관리하는 방법을 실무형 실습을 통해 중점적으로 다룹니다.
이 실습에서는 다음 작업을 수행하는 방법을 배웁니다.
gcloud
클라이언트 설치 및 구성두 개의 사용자 계정과 두 개의 프로젝트로 시작합니다. user1
은 두 프로젝트의 '소유자'이고 user2
는 첫 번째 프로젝트 한정 '뷰어'입니다. 첫 번째 프로젝트에는 실행 중인 Linux 가상 머신(VM)이 있습니다.
Google Cloud는 누가(ID) 어떤 리소스에 어떤 액세스 권한(역할)이 있는지 정의하여 액세스 제어를 관리할 수 있는 Cloud Identity and Access Management(IAM)를 제공합니다.
Cloud IAM을 사용하면 특정 Google Cloud 리소스에 대한 세부적인 액세스 권한을 부여하고 다른 리소스에 대한 무단 액세스를 방지할 수 있습니다. Cloud IAM으로 최소 권한의 보안 원칙을 적용하여 리소스에 대해 필요한 액세스 권한만 부여할 수 있습니다.
Cloud IAM에서는 구성원에 액세스 권한을 제공합니다. 구성원은 다음 유형 중 하나일 수 있습니다.
ID 유형에 대한 자세한 내용은 ID와 관련된 개념 가이드에서 자세히 알아보세요.
이 실습에서는 Google 계정, 서비스 계정, Cloud ID 도메인 그룹을 사용합니다.
역할은 권한 모음입니다. 사용자에게 직접 권한을 할당할 수는 없으며, 대신 역할을 부여해야 합니다. 사용자에게 역할을 부여하면 역할에 포함된 모든 권한이 부여됩니다.
Cloud IAM에는 다음과 같은 세 가지 역할이 있습니다.
기본 역할: 이전부터 Cloud 콘솔에서 사용할 수 있는 역할이며, 지금도 계속 사용 가능합니다. 소유자, 편집자, 뷰어 역할이 여기에 해당합니다.
사전 정의된 역할: 사전 정의된 역할은 기본 역할보다 더욱 세부적인 액세스 제어를 부여하는 Cloud IAM 역할입니다. 예를 들어 사전 정의된 역할인 Pub/Sub 게시자 역할(roles/pubsub.publisher)은 Cloud Pub/Sub 주제에 메시지를 게시할 수 있는 액세스 권한만 제공합니다.
커스텀 역할: 사전 정의된 역할로 요구사항을 충족할 수 없는 경우 조직의 요구사항에 맞게 생성하는 커스텀 역할입니다.
역할에 대한 자세한 내용은 역할 가이드를 참조하세요.
gcloud CLI는 Cloud SDK에 포함되어 있습니다. gcloud 명령줄 도구를 사용하려면 먼저 시스템에 SDK를 다운로드하여 설치하고 초기화해야 합니다. 이 도구를 사용하여 명령줄이나 스크립트 및 기타 자동화에서 여러 가지 일반적인 플랫폼 작업을 수행할 수 있습니다.
기본적으로 SDK는 정식 버전 및 프리뷰 단계에 있는 gcloud CLI 명령어만 설치합니다. 추가 기능은 alpha 및 beta라는 SDK 구성요소에서 사용할 수 있습니다. 이러한 구성요소를 통해 gcloud CLI를 사용하여 Cloud Bigtable, Google Cloud Dataflow, Cloud Platform의 다른 기능을 정식 버전 이전 출시 버전 단계로 사용할 수 있습니다.
gcloud에 대한 자세한 내용은 gcloud CLI 개요 가이드를 참조하세요.
다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.
실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.
이 실습을 완료하려면 다음을 준비해야 합니다.
실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 대화상자가 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 창이 있습니다.
Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).
실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.
팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.
필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.
실습 세부정보 창에서도 사용자 이름을 확인할 수 있습니다.
다음을 클릭합니다.
아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.
실습 세부정보 창에서도 비밀번호를 확인할 수 있습니다.
다음을 클릭합니다.
이후에 표시되는 페이지를 클릭하여 넘깁니다.
잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.
첫 번째 단계는 기존 Google Cloud 컴퓨팅 인스턴스에 연결한 다음 gcloud SDK를 다운로드, 설치, 구성하는 것입니다.
gcloud SDK에는 환경 관리를 지원하는 여러 유틸리티가 있습니다. 먼저 유틸리티에 작업을 수행할 수 있는 권한을 제공하도록 인증을 구성합니다. 인증 프로세스는 사용하는 ID에 따라 다릅니다. 이 예시에서는 실습에서 제공된 ID(사용자 계정)를 사용합니다. 인증이 완료되면 환경을 구성하여 작업할 프로젝트를 정의해야 합니다.
Cloud SDK 도구 승인에 대해 자세히 알아보려면 gcloud CLI 승인 가이드를 참조하세요.
이미 이 실습에는 gcloud
가 설치된 환경을 시뮬레이션하는 centos-clean이라는 Compute Engine 인스턴스가 있습니다. Cloud 콘솔을 사용하여 이 인스턴스에 연결합니다.
탐색 메뉴 > Compute Engine > VM 인스턴스로 이동하여 컴퓨팅 인스턴스 목록을 엽니다.
centos-clean이라는 이름의 컴퓨팅 인스턴스가 포함된 줄에서 SSH를 클릭합니다.
gcloud
가 아직 설치되어 있지 않다면 먼저 테스트합니다. SSH 세션 내에서 다음을 실행합니다.gcloud
환경 구성을 시작합니다. SSH 세션 내에서 다음을 실행합니다.여러 프롬프트가 표시됩니다.
계속하려면 로그인해야 합니다.와 계속하시겠어요(Y/n)? 메시지가 표시되면 Enter 키를 누릅니다.
새 탭에서 브라우저에서 다음 링크로 이동: 메시지 아래의 링크로 이동합니다.
이 실습의 사용자 인증 정보를 사용하여 gcloud
환경을 인증합니다. Compute Engine 인스턴스를 사용하고 있으므로 일반적으로 서비스 계정을 사용합니다. 자체 워크스테이션 환경을 시뮬레이션하는 중이므로 제안을 무시하고 계속 진행합니다. 이 실습의 뒷부분에서 서비스 계정 사용에 대해 살펴보겠습니다.
링크를 클릭하면 Google 계정으로 로그인 웹페이지가 열립니다. 이 실습에 제공된 계정을 클릭합니다(잘 모르겠는 경우 이 페이지의 왼쪽 상단을 확인하세요).
허용을 클릭합니다.
Cloud SDK가 Google 계정과 동일한 액세스 권한을 갖는 것에 동의하는 것입니다.
로그인하려는 머신의 gcloud CLI에 다음 인증 코드를 입력합니다라는 메시지가 표시되면 복사 버튼을 클릭한 다음 SSH 세션으로 돌아가서 승인 코드 입력: 프롬프트에 코드를 붙여넣습니다.
사용할 클라우드 프로젝트 선택:이라는 메시지가 표시되면 목록에서 현재 프로젝트(웹 콘솔 상단에 프로젝트 ID가 표시됨)를 찾은 다음 프로젝트 번호를 입력하여 옵션 목록에서 프로젝트를 선택합니다.
초기화가 완료되고 영역과 리전이 설정된 것을 확인할 수 있습니다. 다음 작업에서 둘 다 변경합니다.
특정 Compute Engine 리소스는 여러 리전과 영역에 상주합니다. 리전은 리소스를 실행할 수 있는 특정한 지리적 위치로, 각 리전에는 영역이 하나 이상 있습니다.
Cloud 콘솔에서 다음 gcloud 명령어를 실행하여 실습의 기본 리전과 영역을 설정합니다.
gcloud
명령줄 도구를 설치하고 기본적으로 구성한 후 컴퓨팅 인스턴스를 생성하여 몇 가지를 변경합니다.
하지만 어떤 크기로 어디에 생성되며 어떤 이미지가 사용될까요?
서비스에서 사용하는 기본값은 여러 가지가 있습니다. 일부는 gcloud
구성에서 제어할 수 있습니다. 예를 들어 인스턴스 위치는 영역 설정으로 제어할 수 있습니다.
compute
섹션, core
섹션, active configuration
이 표시됩니다. 각각을 변경할 수 있지만 이 실습에서는 영역만 변경하겠습니다. VM이 만들어진 영역을 확인합니다.
같은 리전에 있는 다른 영역 중 하나를 선택합니다. 예를 들어 영역이 us-west2-a
라면 us-west2-b
를 선택합니다.
현재 영역을 같은 리전의 다른 영역으로 변경합니다. SSH 세션 내에서 다음을 실행합니다. 이때 ZONE
을 선택한 영역으로 바꿉니다.
명시한 영역에 변경사항이 반영된 것을 확인할 수 있습니다.
gcloud config set
명령어를 사용하여 다른 설정을 변경할 수 있습니다. 이러한 변경사항은 영구적이며 홈 디렉터리에 기록됩니다.
기본 구성은 ~/.config/gcloud/configurations/config_default에 저장됩니다.
인스턴스를 만들 때 기본 영역이 아닌 다른 영역을 사용하려면 --zone switch를 사용하면 됩니다. 예를 들어 gcloud compute instances create lab-1 --zone us-central1-f
를 사용합니다.
구성은 텍스트로만 저장되며 백업이나 복사가 가능함을 확인할 수 있습니다.
이제 gcloud
가 구성되었습니다.
이제 계정을 1개 설정했습니다. 다른 팀에서 작업하거나 다른 계정에 액세스해야 하는 상황에서도 gcloud config
로 관리할 수 있습니다.
다음 작업에서는 두 번째 구성을 만들고 두 구성 간에 전환하는 방법을 알아봅니다.
이 실습에서는 로그온하는 데 사용할 수 있는 두 번째 Google 계정이 있습니다. 이 계정에는 첫 번째 프로젝트에 대해 읽기 전용(뷰어) 액세스 권한이 있습니다. 이제 이 사용자에 대한 새 구성을 만듭니다.
gcloud
구성을 새로 시작합니다. SSH 세션 내에서 다음을 실행합니다.옵션 2인 새 구성 만들기를 선택합니다.
구성 이름: user2를 입력합니다.
새 계정으로 로그인: 옵션 3을 선택하면 제공된 다른 사용자 이름으로 로그인합니다.
계속하시겠어요(Y/n)? 메시지가 표시되면 Enter 키를 누릅니다.
새 탭에 표시된 링크로 이동합니다.
다른 계정 사용을 클릭합니다.
이 페이지(왼쪽)에서 두 번째 사용자 계정을 복사하고 이메일 또는 휴대전화 프롬프트에 붙여넣습니다.
실습을 시작할 때 사용한 것과 동일한 비밀번호를 복사하고 비밀번호 입력 프롬프트에 붙여넣습니다.
이해함을 클릭합니다.
허용을 클릭합니다.
Cloud SDK가 Google 계정과 동일한 액세스 권한을 갖는 것에 동의하는 것입니다.
로그인하려는 머신의 gcloud CLI에 다음 인증 코드를 입력합니다라는 메시지가 표시되면 복사 버튼을 클릭한 다음 SSH 세션으로 돌아가서 승인 코드 입력: 프롬프트에 코드를 붙여넣습니다.
사용할 클라우드 프로젝트 선택:이라는 메시지가 표시되면 현재 프로젝트(웹 콘솔 상단에 프로젝트 ID가 표시됨)를 찾은 다음 프로젝트에 해당하는 번호를 입력합니다.
초기화가 완료되고 영역과 리전이 설정된 것을 확인할 수 있습니다.
이 새 계정에는 프로젝트에 대한 뷰어 전용 액세스 권한이 있으므로 일부 리소스를 보고 생성하여 실제로 이 계정을 사용하고 있는지 테스트해 볼 수 있습니다.
두 번째 사용자 계정에는 뷰어 액세스 권한이 있으므로 centos-clean
과 lab-1
인스턴스가 나열되어 있어야 합니다.
두 번째 사용자 계정에는 뷰어 액세스 권한만 있어 인스턴스를 만들 수 없으므로 이 명령어는 실패합니다. 실패하기까지는 시간이 조금 걸립니다.
이제 원래 사용자 계정의 사용자 인증 정보를 다시 사용합니다. 이후 역할과 권한에 대해 알아보면서 두 계정 간에 전환해야 합니다.
이 프로젝트에는 두 개의 사용자 계정이 제공되어 있습니다. 첫 번째 사용자는 두 프로젝트에 대한 모든 권한이 있으므로 관리자 계정으로 여길 수 있습니다. 두 번째 사용자에게는 두 프로젝트에 대한 뷰어 전용 액세스 권한만 있습니다. 두 번째 사용자를 DevOps 사용자라고 부르며 해당 사용자 ID는 일반적인 DevOps 수준의 사용자를 나타냅니다.
다음으로 gcloud
를 사용하여 버킷 및 인스턴스 생성을 허용하는 프로젝트에 대한 커스텀 역할을 만들어, DevOps 사용자를 위한 하나의 프로젝트에 대한 액세스를 구성합니다.
역할 목록이 반환됩니다. 명령어에 grep "name:"
을 추가하면 반환되는 데이터의 양이 역할 이름만 포함하도록 줄어듭니다.
이러한 역할 중 하나를 조사하여 역할에 할당된 권한을 확인합니다. 권한을 보려면 gcloud iam roles describe
를 사용합니다. 간략히 역할만 보려면 roles/compute.instanceAdmin을 사용합니다.
compute.instanceAdmin
의 사전 정의된 역할을 조사합니다. SSH 세션 내에서 다음을 실행합니다.roles/compute.instanceAdmin에는 많은 권한이 있지만, 나중에 필요한 최소 권한은 다음과 같습니다.
전체 역할 목록과 할당된 권한을 검토하려면 IAM 권한 참조 가이드를 참조하세요.
역할에 권한이 포함되어 있다는 것을 알았으니 이제 사용자 계정에 역할과 그에 따른 모든 관련 권한을 할당하려면 어떻게 해야 할까요?
역할을 연결하는 방법에는 두 가지가 있습니다.
다음으로 두 번째 사용자에게 두 번째 프로젝트에 대해 '뷰어'라는 기본 역할을 연결합니다.
gcloud
구성을 두 번째 사용자(user2)로 다시 전환합니다. SSH 세션 내에서 다음을 실행합니다.이제 다시 user2
가 되었습니다.
bashrc
파일을 추가하므로 주의해야 합니다.WARNING: You do not appear to have access to project [your 2nd project id] or it does not exist
라는 경고가 표시됩니다.
N
을 입력하고 Enter 키를 누릅니다.이는 PROJECTID2 프로젝트에 대한 액세스 권한이 없다는 의미입니다. 이 부분은 곧 수정합니다.
두 번째 사용자에게 액세스 권한을 부여할 수 있는 권한이 있는 첫 번째 사용자로 다시 전환해야 합니다.
USERID2
값을 두 번째 사용자 이름으로 설정하고 두 번째 사용자에게 두 번째 프로젝트에 대한 뷰어 역할을 바인딩합니다.
먼저 jq
를 설치합니다.
명령어를 실행하면 텍스트가 다음과 같이 표시됩니다. 위로 스크롤해야 할 수도 있습니다.
이번에는 오류 메시지가 표시되지 않을 것입니다.
이 프로젝트에서는 인스턴스가 0개 표시됩니다.
user2는 프로젝트에 대한 뷰어 권한만 있기 때문에 이 명령어는 실패합니다.
이제 원래 사용자 계정의 사용자 인증 정보를 다시 사용합니다.
다음으로 DevOps팀에 필요한 권한 집합이 있는 새 역할을 만듭니다.
devops
라는 커스텀 역할을 만듭니다. SSH 세션 내에서 다음을 실행합니다.이 명령어는 프로젝트에 인스턴스를 만들고 관리하는 권한이 있는 devops
라는 커스텀 역할을 만듭니다.
역할의 전체 이름이 나열되며, 역할이 프로젝트 내에 있으므로 경로는 projects/PROJECT/roles/ROLENAME
패턴입니다.
역할을 만들었으니 사용자와 역할을 프로젝트에 바인딩해야 합니다. gcloud projects add-iam-policy-binding
을 사용하여 바인딩합니다. 이 명령어를 더 쉽게 실행하기 위해 먼저 프로젝트 ID와 사용자 계정 등 몇 가지 환경 변수를 설정합니다.
iam.serviceAccountUser
역할을 바인딩합니다. SSH 세션 내에서 다음을 실행합니다.서비스 계정이 연결된 인스턴스를 만들려면 권한이 필요합니다. iam.serviceAccountUser
역할에는 이러한 권한이 있으므로 이 사전 정의된 역할을 사용합니다.
devops
라는 커스텀 역할을 바인딩합니다. 이 페이지 왼쪽에서 두 번째 사용자 계정을 찾을 수 있습니다. 두 번째 사용자 계정에 USERID를 설정했는지 확인합니다.SSH 세션 내에서 다음을 실행합니다.
명령어를 실행하면 텍스트가 아래 예시와 같이 표시됩니다. 위로 스크롤해야 할 수도 있습니다.
이제 다시 user2가 되었습니다.
이제 user2가 인스턴스를 생성할 수 있습니다.
마지막으로 변경 후 환경은 다음과 같습니다.
gcloud
를 사용하여 인증하고 역할을 통해 Google Cloud 서비스에 액세스하는 방법을 살펴보았습니다. 이제 일반적인 접근방식을 살펴보겠습니다.
애플리케이션 프로그래밍 인터페이스(API)를 사용하여 Cloud Storage 버킷을 읽고 쓰는 애플리케이션이 있습니다. 새 서버를 시작할 때마다 인증을 받아야 한다면 번거로울 뿐만 아니라 클라우드의 사용 취지와도 맞지 않으므로 서비스 계정을 사용합니다.
서비스 계정은 개별 최종 사용자가 아닌, 애플리케이션 또는 가상 머신(VM)에 속한 특별한 Google 계정입니다. 애플리케이션은 서비스 계정을 사용하여 서비스의 Google API를 호출하므로 사용자가 직접 관여하지 않습니다.
서비스 계정에 대한 자세한 내용은 서비스 계정 가이드를 참조하세요.
이제 서비스 계정을 만들고 해당 서비스 계정을 컴퓨팅 인스턴스와 함께 사용한 다음 서비스 계정에서 필요한 액세스 권한이 허용되는지 테스트합니다.
user2
에는 서비스 계정을 설정하고 구성할 수 있는 권한이 없습니다. SSH 세션 내에서 다음을 실행합니다.PROJECTID2
로 설정합니다. SSH 세션 내에서 다음을 실행합니다.알맞은 프로젝트를 대상으로 하는지 확인합니다.
SA
라는 로컬 변수에 넣습니다. SSH 세션 내에서 다음을 실행합니다.이 명령어는 SA 로컬 변수를 서비스 계정의 이메일 주소로 설정합니다. 정말 유용한 명령어입니다.
iam.serviceAccountUser
역할을 부여합니다. SSH 세션 내에서 다음을 실행합니다.이 역할을 통해 서비스 계정으로 컴퓨팅 인스턴스에 서비스 계정을 할당할 수 있습니다.
compute.instanceAdmin
역할을 부여합니다. SSH 세션 내에서 다음을 실행합니다.이 역할을 통해 서비스 계정으로 컴퓨팅 인스턴스를 관리할 수 있습니다.
액세스 범위는 인스턴스에 권한을 지정하는 기존 방법입니다. 액세스 범위는 보안 메커니즘이 아닙니다. 대신 gcloud
도구 또는 클라이언트 라이브러리의 요청에 사용되는 기본 OAuth 범위를 정의합니다. gRPC 또는 SignBlob API와 같은, OAuth를 통해 인증되지 않는 요청을 수행할 때는 아무런 영향을 주지 않습니다.
서비스 계정으로 실행되도록 인스턴스를 구성할 때는 액세스 범위를 설정해야 합니다.
인스턴스에 전체 cloud-platform 액세스 범위를 설정한 후 IAM 역할을 통해 서비스 계정의 API 액세스 권한을 안전하게 제한하는 것이 가장 좋습니다.
액세스 범위는 인스턴스별로 적용됩니다. 인스턴스를 만들 때 액세스 범위를 설정합니다. 액세스 범위는 인스턴스 수명 동안에만 유지됩니다.
서비스 계정이 속한 프로젝트에서 관련 API를 사용 설정하지 않았으면 액세스 범위가 적용되지 않습니다. 예를 들어 가상 머신 인스턴스에서 Cloud Storage에 액세스 범위를 부여하면 프로젝트에서 Cloud Storage API를 사용 설정한 경우에만 인스턴스가 Cloud Storage API를 호출할 수 있습니다.
gcloud compute ssh
를 사용하여 새로 만든 인스턴스에 연결합니다. SSH 세션 내에서 다음을 실행합니다.계속 진행할지 묻는 메시지가 표시되면 Enter 키를 누릅니다.
비밀번호 생성 단계를 건너뛰려면 Enter 키를 두 번 누릅니다.
gcloud
구성이 포함되어 있습니다. SSH 세션 내에서 다음을 실행합니다.구성에는 서비스 계정이 포함되어 있습니다.
Enter 키를 눌러 이 VM의 기본 영역을 수락합니다.
서비스 계정에 권한이 있으므로 인스턴스가 나열되었음을 확인할 수 있습니다.
Cloud SDK 도구(gcloud
)를 사용하여 gcloud 클라이언트를 설치 및 구성하고, 여러 IAM 구성을 관리하고, 적절한 IAM 권한을 할당하고, 서비스 계정을 사용했습니다. 이러한 작업은 액세스 제어를 위해 명령줄 도구를 사용할 때 Google Cloud IAM과 Azure IAM 간의 유사점을 보여줍니다. 두 인터페이스 모두에서 계정/역할을 프로비저닝하고, 서비스 계정/역할을 만들고, 사용자를 전환할 수 있습니다.
Azure IAM과 Google Cloud IAM은 역할 기반 액세스 제어(RBAC) 측면에서 유사한 점도 있지만 차이점도 있습니다. 실습에서 살펴본 주요 차이점 중 하나는 서비스 계정 생성 프로세스입니다. Google Cloud에서는 계정을 등록하고 서비스 주 구성원 이름을 만들지 않기 때문입니다. Google Cloud의 프로젝트는 Azure의 테넌트와 유사하게 작동합니다. gcloud 명령줄 도구를 사용하여 여러 프로젝트에 걸쳐 계정을 프로비저닝했습니다. 이는 Azure CLI를 사용하여 여러 테넌트에 걸쳐 액세스를 프로비저닝하는 방식과 유사합니다.
Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.
설명서 최종 업데이트: 2024년 7월 4일
실습 최종 테스트: 2024년 7월 4일
Copyright 2025 Google LLC. All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.
현재 이 콘텐츠를 이용할 수 없습니다
이용할 수 있게 되면 이메일로 알려드리겠습니다.
감사합니다
이용할 수 있게 되면 이메일로 알려드리겠습니다.
한 번에 실습 1개만 가능
모든 기존 실습을 종료하고 이 실습을 시작할지 확인하세요.