Um usuário representa uma conta autenticada que pode acessar uma organização e as
entidades dentro dela, como ambientes, proxies de API e keystores.
Para adicionar um novo usuário à sua organização da Apigee, primeiro conceda acesso à conta
dele no projeto do Cloud e depois na IU da Apigee. Neste documento, os termos usuário e conta de usuário são usados de forma intercambiável.
Ao adicionar um novo usuário, você normalmente faz o seguinte:
No console, atribua o novo usuário a um ou mais papéis no seu projeto do Cloud. Dessa forma, o usuário tem acesso amplo a todos os ambientes da organização.
Na IU da Apigee, conceda papéis de usuário adicionais em um ou mais ambientes da sua organização da Apigee. Observe que os papéis de usuário com escopo de ambiente não substituem
os papéis concedidos no nível do Google Cloud, eles são aditivos.
Os recursos que você concede à conta de usuário dependem do tipo de papel
atribuído a eles. Um papel representa um conjunto de permissões.
Não é possível conceder uma permissão ao usuário diretamente. Em vez disso, você concede a eles um papel. Por
exemplo, é possível atribuir um desenvolvedor ao papel de API Admin para que
ele possa criar proxies de API, KVM e fluxos compartilhados. Para alguém que implantará
proxies, atribua o papel de Environment Admin, que concede a capacidade de
implantar e remover a implantação de revisões de proxy de API. Para detalhes sobre todos os papéis da Apigee, consulte
Papéis da Apigee.
Além disso, os recursos que um usuário pode acessar com base no papel dependem de onde
você atribuiu o papel:
Projeto do Google Cloud: se você atribuir um papel no Console do Cloud (no projeto do Cloud),
o usuário poderá acessar todos os recursos da Apigee, todos os ambientes e recursos dentro
deles, nesse papel. Isso ocorre porque o projeto do Cloud é o pai
da IU da Apigee na hierarquia de recursos. As permissões definidas no pai (o projeto
do Cloud) são herdadas por todos os filhos (ambientes). É possível refinar esse acesso
especificando os papéis de usuário por ambiente na IU da Apigee.
O controle de acesso no Google Cloud Platform é feito com o gerenciamento de identidade e acesso
(IAM). O IAM permite que você defina permissões especificando quem tem
que tipo de acesso a quais recursos do projeto. Para mais informações, consulte Conceitos relacionados à identidade.
Os usuários são um tipo de principal, um termo amplo que se refere a uma identidade que pode receber
acesso a recursos. Outros tipos de principais do Cloud incluem contas de serviço, Grupos do Google e domínios
do G Suite. Para mais informações, consulte
esta visão geral do Cloud Identity and Access Management.
Acesso ao ambiente: conceder um papel de usuário a um ambiente específico não substitui papéis definidos no nível do projeto do Google Cloud. No nível do ambiente, os papéis concedidos a um usuário são representados como uma união com todos os papéis do Cloud atribuídos a ele.
Por exemplo, se você definir um usuário como API Admin no projeto do Cloud, ele vai ter acesso, como API Admin, a todos os ambientes da organização.
Recomendações de papéis
A Apigee recomenda que você faça o seguinte para cada nova conta de usuário adicionada. (Essas etapas não são necessárias ao adicionar superusuários ou administradores.)
No Console do Cloud, adicione a nova conta de usuário e selecione um papel com um conjunto mínimo de
permissões. Por exemplo, defina o papel de um novo usuário como API Admin. Consulte Como gerenciar o acesso no Google Cloud.
Na visualização Acesso ao ambiente da IU da Apigee, adicione o usuário e defina os
funções do usuário adicionais para cada ambiente na organização, conforme descrito em
Gerenciar usuários. Observe que
os papéis com escopo de ambiente definidos na IU da Apigee não substituem os papéis definidos no nível do Google Cloud.
Eles são aditivos.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-21 UTC."],[[["\u003cp\u003eThis document applies to both Apigee and Apigee hybrid, and it details how to manage user accounts within an Apigee organization.\u003c/p\u003e\n"],["\u003cp\u003eAdding a new user involves assigning roles in both the Google Cloud project and the Apigee UI, granting them access to organization-wide resources and specific environments, respectively.\u003c/p\u003e\n"],["\u003cp\u003eRoles assigned at the Google Cloud project level provide broad access across all environments, while roles assigned in the Apigee UI offer additive, environment-specific permissions.\u003c/p\u003e\n"],["\u003cp\u003eApigee recommends assigning minimal permissions at the Cloud project level and then refining access in the Apigee UI for each specific environment, ensuring a granular control over user access.\u003c/p\u003e\n"],["\u003cp\u003eUser roles determine the capabilities a user has, based on a collection of permissions, such as creating API proxies, deploying, and undeploying API proxy revisions.\u003c/p\u003e\n"]]],[],null,["# Users and roles\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nA *user* represents an authenticated account that can access an organization and the\nentities within that organization, such as the environments, API proxies, and keystores.\n\nTo add a new user to your Apigee organization, you grant access to the user's *account,* first in the Cloud project and then in the Apigee UI. (This document uses the terms *user*\nand *user account* interchangeably.)\n\nWhen you add a new user, you typically:\n\n1. **In the Console** , assign the new user to one or more roles in your Cloud project. This gives the user broad access to all environments in the organization.\n\n For more information, see\n [Managing access in the\n Console](/apigee/docs/api-platform/system-administration/manage-access).\n2. **In the Apigee UI** , grant additional user roles in one or more environments in your Apigee organization. Note that environment-scoped user roles do not supersede roles granted at the Google Cloud level; they are additive.\n\n For more information, see\n [Manage users in the\n Apigee UI](/apigee/docs/api-platform/system-administration/manage-users).\n\n| **Note:** You do not have to assign the same role for a user in the Apigee UI for each environment that you assigned to the user for the Cloud project.\n\nAbout roles\n-----------\n\nThe capabilities that you grant to the user account depend on the type of *role* that you\nassign to them. A role is a collection of [permissions](/iam/docs/overview#permissions).\nYou cannot grant a permission to the user directly. Instead, you grant them a role. For\nexample, you might assign a developer to the role of `API Admin` so that\nthey can create API proxies, , and shared flows. For someone that will deploy\nproxies, you might assign them to the role of `Environment Admin`, which grants them the ability to\ndeploy and undeploy API proxy revisions. For details about all Apigee roles, see\n[Apigee roles](/apigee/docs/api-platform/system-administration/apigee-roles).\n\nAdditionally, the resources that a user can access based on their role depends on *where*\nyou assigned the role:\n\n- **Google Cloud project** - If you assign a role in the Console (on the Google Cloud project), then the user can access all Apigee resources---*all environments and resources within\n those environments* ---in that role. This is because the Cloud project is the *parent* of the Apigee UI in the resource hierarchy; the permissions set on the parent (the Cloud project) are inherited by all children (environments). You can refine this access by specifying user roles on a *per environment* basis in the Apigee UI.\n\n Access control in Google Cloud Platform is controlled by Identity and Access Management\n (IAM). IAM lets you set permissions specifying **who** has\n **what** kind of access to **which** resources in your project. For\n more information, see [Concepts related to\n identity](/iam/docs/overview#concepts_related_identity).\n\n Users are a type of *principal* , a broad term that refers to an identity that can be granted\n access to resources. Other types of Cloud principals include service accounts, Google groups, and G Suite\n domains. For more information, see\n [this overview](/iam/docs/overview#concepts_related_identity) of Cloud Identity and\n Access Management.\n- **Environment access** - Granting a user role for a specific environment does not supersede roles set at the Google Cloud project level. At the environment level, roles granted to a user are represented as a union with any Cloud roles assigned to the user.\n\nFor example, if you define a user as an `API Admin` on the Cloud project, then that user will have access---as an\n`API Admin`--- to all environments in your organization.\n\n### Role recommendations\n\nApigee recommends that you do the following for each new user account that you add. (When adding\n*super users* or administrators, this is not necessary.):\n\n1. In the Console, add the new user account and select a role that has a minimal set of permissions. For example, set the role of a new user to `API Admin`. See [Managing access in Google Cloud](/apigee/docs/api-platform/system-administration/manage-access).\n2. In the Apigee UI's **Environment Access** view, add the user and set any additional user roles for each environment in the organization as described in [Manage users](/apigee/docs/api-platform/system-administration/manage-users). Note that environment-scoped roles set in the Apigee UI do not supersede roles set at the Google Cloud level, they are additive.\n\n*[KVM]: Key Value Map"]]
