[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-03。"],[[["\u003cp\u003eApplication Integration uses Identity and Access Management (IAM) to manage access control, allowing management at both the project and resource levels by assigning roles to principals.\u003c/p\u003e\n"],["\u003cp\u003eService accounts, which can be user-managed or the default account, are granted IAM roles to perform tasks and operations, with user-managed accounts' access being further restricted by roles and access scopes.\u003c/p\u003e\n"],["\u003cp\u003eThe appropriate IAM roles must be granted to a service account to allow it to access relevant API methods, ensuring that any integration attached to that service account inherits the conferred authorization.\u003c/p\u003e\n"],["\u003cp\u003eWhen configuring authentication, OAuth 2.0 profiles take precedence over user-managed service accounts, and if neither is configured, the default service account is used.\u003c/p\u003e\n"],["\u003cp\u003eAccess scopes serve as a legacy method for determining authorization for your integration, but they are limited to the OAuth 2.0 protocol and do not apply to other authentication protocols.\u003c/p\u003e\n"]]],[],null,["# Access control overview\n\nSee the [supported connectors](/integration-connectors/docs/connector-reference-overview) for Application Integration.\n\nAccess control overview\n=======================\n\n\nWhen you create a Google Cloud project, you are the only principal on the project. By default, no other principals (users, groups, or [service accounts](#sa)) have access to your project or its resources. After successfully provisioning Application Integration in your project, you can add new principals and set access control for your Application Integration resources.\n\n\nApplication Integration uses [Identity and Access Management (IAM)](/iam) to manage access control within your project. You can use IAM to manage access at the project level or at the resource level:\n\n- To grant access to resources at the project level, assign one or more [roles](#roles) to a principal.\n- To grant access to a specific resource, set an IAM policy on that resource. The resource must support resource-level policies. The policy defines which roles are assigned to which principals.\n\nIAM roles\n---------\n\n\nEvery principal in your Google Cloud project is granted a role with specific permissions. When you add a principal to a project or to a resource, you specify which roles to grant them. Each IAM role contains a set of permissions that allows the principal to perform specific actions on the resource.\n\n\nFor more information about the different types of roles in IAM, see [Understanding roles](/iam/docs/understanding-roles).\n\n\nFor information on granting roles to principals, see [Granting, changing, and revoking access](/iam/docs/granting-changing-revoking-access).\n\n\nApplication Integration provides a specific set of [predefined IAM roles](/application-integration/docs/integrations-access-permissions). You can use these roles to provide access to specific Application Integration resources and prevent unwanted access to other Google Cloud resources.\n\nService accounts\n----------------\n\n\nService accounts are Google Cloud accounts associated with your project that can perform tasks or operations on your behalf. Service accounts are assigned roles and permissions in the same way as principals, using IAM. For more information about service accounts and the different types of service accounts, see [IAM service accounts](/iam/docs/service-accounts).\n\nYou must [grant the appropriate IAM roles to a service account](/iam/docs/granting-roles-to-service-accounts) to allow that service account access to relevant API methods.\nWhen you grant an IAM role to a service account, any integration that has that service account attached will have the authorization conferred by that role. If there isn't a predefined role for the access level you want, you can create and grant [custom roles](/iam/docs/understanding-custom-roles).\n\nApplication Integration uses two types of service accounts:\n\n- [User-managed service account](#user-managed-service-account)\n- [Default service account](#default-service-account)\n\n### User-managed service account\n\nA user-managed service account can be attached to an integration\nto provide credentials to execute the task. For more information, see [User-managed service accounts](/iam/docs/service-account-types#user-managed).\n\nThe authorization provided to the integration is limited by two separate configurations: the\n[roles granted to the attached service account](#usingroles), and the access scopes.\nBoth of these configurations must allow access before the integration can execute the task.\n\nA user-managed service account has the following email address: \n\n```\nservice-account-name@PROJECT_ID.iam.gserviceaccount.com\n```\n\n### Default service account\n\nNew Google Cloud projects that have provisioned Application Integration have an Application Integration [default service account](/iam/docs/service-account-types#default), which has the following email address: \n\n```\nservice-PROJECT_NUMBER@gcp-sa-integrations.iam.gserviceaccount.com\n```\n\n\nThe Application Integration default service account is created during provisioning and is automatically added to your project with the basic IAM roles and permissions. For more information, see [Default service accounts](/iam/docs/service-account-types#default).\n\n\nFor information on granting additional roles or permissions to the default service account, see [Granting, changing, and revoking access](/iam/docs/granting-changing-revoking-access).\n\nAdd a service account\n---------------------\n\nApplication Integration provides two ways to add a service account to your integration:\n\n- If you have [enabled governance for your region](/application-integration/docs/enable-new-region#provision-new-region), then you must add a service account while [creating a new integration](/application-integration/docs/create-integrations).\n- If you have not enabled governance, then you can optionally add a service account to your integration. To add a service account to an existing integration, see [Edit and view integrations](/application-integration/docs/view-integration-details).\n\nAuthentication rule\n-------------------\n\nIf your integration has both OAuth 2.0 profile and a user-managed service account configured, then by default the OAuth 2.0 profile is used for authentication. If neither OAuth 2.0 profile nor user-managed service account is configured, then the default service account (`service-`\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`@gcp-sa-integrations.iam.gserviceaccount.com`) is used. If the task does not use the default service account, the execution fails.\n\nAuthorization rule\n------------------\n\nIf you attach a service account to your integration, you must determine the level\nof access the service account has by the IAM roles that you\n[grant to the service account](/iam/docs/granting-roles-to-service-accounts).\nIf the service account has no IAM roles, then no resources can\nbe accessed using the service account.\n\nAccess scopes potentially further limit access to API\nmethods when authenticating through OAuth. However, they do not extend to other\nauthentication protocols like gRPC.\n\n### IAM roles\n\nYou must [grant the appropriate IAM roles to a service account](/iam/docs/granting-roles-to-service-accounts) to allow that service account access to relevant API methods.\n\nWhen you grant an IAM role to a service account, any integration that has that\nservice account attached will have the authorization conferred by that role.\n\n### Access scopes\n\nAccess scopes are the legacy method of specifying authorization for your\nintegration. They define the default OAuth scopes used in requests from the\ngcloud CLI or the client libraries. Scopes let you specify access permissions\nfor users. You can specify multiple scopes separated by a single space (\" \"). For more information, see\n[OAuth 2.0 Scopes for Google APIs](https://developers.google.com/identity/protocols/oauth2/scopes). For user-managed service accounts, the scope is predefined to the following scope: \n\n```\nhttps://www.googleapis.com/auth/cloud-platform\n```"]]
