이 페이지는 Cloud Translation API를 통해 번역되었습니다.

액세스 제어 설정

액세스 제어를 사용하면 Google Cloud 프로젝트의 서비스와 리소스에 액세스할 수 있는 사용자를 지정할 수 있습니다. App Engine에는 액세스 제어를 설정하는 몇 가지 사용 사례가 있습니다.

서비스를 설정하고 앱을 배포할 수 있도록 Google Cloud 프로젝트에 대한 액세스 권한을 팀 구성원에게 부여합니다.
Cloud Storage와 같은 Google Cloud 서비스에 대한 액세스 권한을 앱에 부여합니다. 모든 Cloud 서비스에서는 App Engine 앱의 호출을 포함한 모든 API 호출을 인증 및 승인해야 합니다.
Google Cloud 프로젝트의 리소스에 대한 액세스 권한을 사용자에게 부여합니다. 이 사용 사례는 일반적이지 않지만 앱이 사용자를 대신하여 Cloud 리소스에 대한 액세스 권한을 요청해야 할 수 있습니다. 예를 들어 앱이 사용자의 데이터에 액세스해야 할 수 있습니다.

이 페이지에서는 각 사용 사례에서 액세스 제어를 설정하는 방법을 간략하게 설명합니다.

Google Cloud Platform에서 액세스 제어를 처리하는 방법에 대한 배경 정보는 Identity and Access Management(IAM) 개요를 참조하세요.

팀 구성원에 액세스 권한 부여

개발자에게 Google Cloud 프로젝트에 대한 액세스 권한을 부여하려면 다음 중 하나를 만들거나 둘 다 만듭니다.

사용자 계정 - Google 계정과 연결되어 있으며 프로젝트의 특정 사용자를 나타냅니다.

사용자 계정을 사용하여 다음 도구에서 인증할 수 있습니다.
- Google Cloud 콘솔
- Google Cloud CLI
- gcloud CLI를 사용하여 App Engine 앱을 테스트하고 배포하는 IDE 및 빌드 도구
서비스 계정 - 사용자가 아닌 애플리케이션이나 프로세스를 나타냅니다. 특히 여러 개발자가 이러한 프로세스를 실행할 수 있는 경우 자동화된 빌드, 테스트, 배포 프로세스에서 서비스 계정을 사용합니다.

서비스 계정을 사용하여 다음 도구에서 인증할 수 있습니다.
- gcloud CLI
- gcloud CLI를 사용하여 App Engine 앱을 테스트하고 배포하는 IDE 및 빌드 도구

사용자 계정 만들기

Google Cloud 콘솔에서 IAM 페이지를 엽니다.
IAM 페이지 열기
프로젝트 선택을 클릭하고 프로젝트를 선택한 다음 열기를 클릭합니다.
추가를 클릭합니다.
이메일 주소를 입력합니다.
App Engine 기능에 대한 액세스 권한을 부여하는 역할을 선택합니다.

사용자가 다른 Cloud 서비스에 액세스해야 하는 경우 다른 Cloud 서비스에 대한 액세스 권한을 부여하는 역할을 선택합니다.
저장을 클릭합니다.

이제 사용자가 Google Cloud 콘솔에 로그인하고 gcloud CLI를 승인할 수 있습니다.

gcloud, REST API 또는 클라이언트 라이브러리에서도 사용자 계정을 만들 수 있습니다.

서비스 계정 만들기

Google Cloud 콘솔에서 서비스 계정 페이지를 엽니다.
서비스 계정 페이지 열기
프로젝트를 선택하고 열기를 클릭합니다.
서비스 계정 만들기를 클릭합니다.
서비스 계정 이름을 이 이름은 사용자 친화적인 표시 이름이어야 합니다.
만들기를 클릭합니다.
App Engine 기능에 대한 액세스 권한을 부여하는 역할을 선택합니다.

서비스 계정이 다른 Cloud 서비스에도 액세스해야 하는 경우 다른 Cloud 서비스에 대한 액세스 권한을 부여하는 역할을 선택합니다.
계속을 클릭합니다.
원하는 경우 서비스 계정을 관리할 수 있는 사용자 계정을 지정합니다. 서비스 계정을 사용하여 서비스 계정에서 액세스한 모든 리소스에 간접적으로 액세스할 수 있는 사용자 계정을 지정할 수도 있습니다.
저장을 클릭합니다.

기존 서비스 계정 목록이 나타납니다.
선택적으로 Google Cloud 외부에서 서비스 계정을 사용해야 하는 경우 안내에 따라 서비스 계정 키를 만듭니다.

다음 단계

자동 빌드 및 배포 프로세스에서 서비스 계정을 사용하는 경우 서비스 계정으로 gcloud CLI를 승인합니다.
IDE에서 서비스 계정을 사용하는 경우 IDE에서 제공하는 안내를 따릅니다.
다른 Google Cloud 서비스에 액세스하거나 작업을 실행할 때 App Engine 앱 버전에 고유한 ID를 사용해야 하는 경우 App Engine에서 사용자 관리 서비스 계정을 지정할 수 있습니다.

Cloud 서비스에 앱 액세스 권한 부여

App Engine 앱에서 Cloud Storage와 같은 다른 Cloud 서비스로 호출을 포함하여 Cloud 서비스에 대한 모든 호출을 인증하고 승인해야 합니다.

App Engine 앱에서 동일한 프로젝트의 서비스로 호출은 기본적으로 승인됩니다. 기본 작동 방식 흐름은 다음과 같습니다.

Cloud 서비스에 대한 호출을 시작할 수 있도록 앱은 서비스와 상호작용에 필요한 사용자 인증 정보 및 기타 데이터가 포함된 클라이언트 객체를 만듭니다. 클라이언트 생성자에 사용자 인증 정보를 지정하지 않으면 클라이언트는 앱 환경에서 사용자 인증 정보를 찾습니다.

다음은 Cloud Storage용 클라이언트를 만드는 예시입니다.

Go


// implicit uses Application Default Credentials to authenticate.
func implicit() {
	ctx := context.Background()

	// For API packages whose import path is starting with "cloud.google.com/go",
	// such as cloud.google.com/go/storage in this case, if there are no credentials
	// provided, the client library will look for credentials in the environment.
	storageClient, err := storage.NewClient(ctx)
	if err != nil {
		log.Fatal(err)
	}
	defer storageClient.Close()

	it := storageClient.Buckets(ctx, "project-id")
	for {
		bucketAttrs, err := it.Next()
		if err == iterator.Done {
			break
		}
		if err != nil {
			log.Fatal(err)
		}
		fmt.Println(bucketAttrs.Name)
	}

	// For packages whose import path is starting with "google.golang.org/api",
	// such as google.golang.org/api/cloudkms/v1, use NewService to create the client.
	kmsService, err := cloudkms.NewService(ctx)
	if err != nil {
		log.Fatal(err)
	}

	_ = kmsService
}

Java

static void authImplicit() {
  // If you don't specify credentials when constructing the client, the client library will
  // look for credentials via the environment variable GOOGLE_APPLICATION_CREDENTIALS.
  Storage storage = StorageOptions.getDefaultInstance().getService();

  System.out.println("Buckets:");
  Page<Bucket> buckets = storage.list();
  for (Bucket bucket : buckets.iterateAll()) {
    System.out.println(bucket.toString());
  }
}

Node.js

// Imports the Google Cloud client library.
const {Storage} = require('@google-cloud/storage');

// Instantiates a client. If you don't specify credentials when constructing
// the client, the client library will look for credentials in the
// environment.
const storage = new Storage();
// Makes an authenticated API request.
async function listBuckets() {
  try {
    const results = await storage.getBuckets();

    const [buckets] = results;

    console.log('Buckets:');
    buckets.forEach(bucket => {
      console.log(bucket.name);
    });
  } catch (err) {
    console.error('ERROR:', err);
  }
}
listBuckets();

PHP

// Imports the Cloud Storage client library.
use Google\Cloud\Storage\StorageClient;

/**
 * Authenticate to a cloud client library using a service account implicitly.
 *
 * @param string $projectId The Google project ID.
 */
function auth_cloud_implicit($projectId)
{
    $config = [
        'projectId' => $projectId,
    ];

    # If you don't specify credentials when constructing the client, the
    # client library will look for credentials in the environment.
    $storage = new StorageClient($config);

    # Make an authenticated API request (listing storage buckets)
    foreach ($storage->buckets() as $bucket) {
        printf('Bucket: %s' . PHP_EOL, $bucket->name());
    }
}

Python

def implicit():
    from google.cloud import storage

    # If you don't specify credentials when constructing the client, the
    # client library will look for credentials in the environment.
    storage_client = storage.Client()

    # Make an authenticated API request
    buckets = list(storage_client.list_buckets())
    print(buckets)

Ruby

# project_id = "Your Google Cloud project ID"

require "google/cloud/storage"

# If you don't specify credentials when constructing the client, the client
# library will look for credentials in the environment.
storage = Google::Cloud::Storage.new project: project_id

# Make an authenticated API request
storage.buckets.each do |bucket|
  puts bucket.name
end

기본적으로 앱 환경에는 기본 App Engine 서비스 계정의 사용자 인증 정보가 포함되어 있습니다.
이 서비스 계정은 App Engine 앱을 만들 때 Google에서 생성되고 Google Cloud 프로젝트의 모든 Cloud 서비스를 관리 및 사용할 수 있는 전체 권한을 갖습니다.

다음 중 한 가지 방법으로 이 기본 흐름을 재정의할 수 있습니다.

GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 설정합니다. 이 변수가 설정되면 Cloud 서비스가 기본 서비스 계정 대신 변수에 지정된 사용자 인증 정보를 사용합니다.
Cloud 서비스의 Client 객체를 인스턴스화할 때 사용자 인증 정보를 지정합니다. 예를 들어 앱이 다른 프로젝트의 Cloud 서비스를 호출하는 경우 직접 사용자 인증 정보를 전달해야 할 수도 있습니다.

코드에서 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 설정하거나 사용자 인증 정보를 전달하는 경우 다음 중 한 가지 방법으로 사용자 인증 정보를 저장하는 것이 좋습니다.

사용자 인증 정보를 Datastore 모드의 Firestore(Datastore)와 같은 안전한 위치에 저장하고 런타임 시 검색합니다.
사용자 인증 정보를 코드에 보관하되 Cloud KMS와 같은 키 저장소로 암호화합니다.

각 방식의 장점에 대한 자세한 내용은 보안 비밀 관리 솔루션 선택을 참조하세요.

사용자에게 Cloud 리소스에 대한 액세스 권한 부여

앱이 다른 Google 서비스의 사용자 데이터를 읽도록 하려면 웹 서버 애플리케이션용 OAuth 2.0을 설정해야 합니다. 예를 들어 Google 드라이브의 사용자 데이터를 앱으로 가져오려면 웹 서버 애플리케이션용 OAuth 2.0을 사용하여 특정 데이터를 공유하면서 사용자 이름, 비밀번호와 같은 기타 데이터를 비공개로 유지합니다.

Google Workspace 도메인 전체 권한 위임

Google Workspace(이전의 G Suite) 도메인이 있는 경우 도메인 관리자는 애플리케이션이 사용자 데이터에 액세스할 수 있도록 Google Workspace 도메인 사용자 대신 승인할 수 있습니다. 예를 들어 Google Calendar API를 통해 Google Workspace 도메인에 속한 모든 사용자의 캘린더에 이벤트를 추가하는 애플리케이션은 서비스 계정을 사용하여 Google Calendar API에 사용자 대신 액세스합니다.

도메인의 사용자 대신 데이터에 액세스하도록 서비스 계정을 승인하는 것을 서비스 계정에 대한 '도메인 전체 권한 위임'이라 합니다. 여기에도 OAuth 2.0이 사용되며 Google Workspace 도메인 관리자가 서비스 계정에 대한 도메인 전체 권한을 승인해야 합니다.

서비스 계정 지정

App Engine에서는 두 가지 유형의 서비스 계정을 사용할 수 있습니다.

버전별 서비스 계정: 배포된 서비스의 특정 버전에 대한 ID로 구성된 서비스 계정입니다. 기존 버전 또는 새 버전을 배포할 때 해당 버전의 ID로 작동할 서비스 계정을 지정할 수 있습니다. 예를 들어 앱 수준 기본 서비스 계정과 다른 권한이 버전에 필요하면 해당 버전과 관련된 서비스 계정을 할당할 수 있습니다. 자세한 내용은 App Engine 서비스 계정 구성을 참고하세요.

앱 수준 기본 서비스 계정: 버전별 서비스 계정을 구성하지 않으면 Google Cloud는 배포된 모든 서비스에 앱 수준 기본 서비스 계정을 사용합니다. 앱을 만들 때 앱 수준 기본 서비스 계정을 할당합니다. 자세한 내용은 앱 수준 기본 서비스 계정 할당을 참고하세요.

앱 수준 기본 서비스 계정을 할당하지 않으면 Google Cloud는 자동으로 생성된 App Engine 기본 서비스 계정(PROJECT_ID@appspot.gserviceaccount.com)을 사용합니다.

조직 정책 구성에 따라 프로젝트에 대한 편집자 역할이 기본 서비스 계정에 자동으로 부여될 수 있습니다. iam.automaticIamGrantsForDefaultServiceAccounts 조직 정책 제약조건을 적용하여 자동 역할 부여를 중지하는 것이 좋습니다. 2024년 5월 3일 이후에 조직을 만든 경우 기본적으로 이 제약조건이 적용됩니다.

자동 역할 부여를 중지한 경우 기본 서비스 계정에 부여할 역할을 결정한 후 직접 이러한 역할을 부여해야 합니다.

기본 서비스 계정에 이미 편집자 역할이 있으면 편집자 역할을 권한이 더 낮은 역할로 바꾸는 것이 좋습니다. 서비스 계정 역할을 안전하게 수정하려면 정책 시뮬레이터를 사용하여 변경사항의 영향을 확인한 후 적절한 역할을 부여하고 취소합니다.