> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Usuários e grupos > Adicionar pessoas a uma organização, o que é um convite e por que um grupo é quase sempre o local certo para anexar uma política. Um usuário é uma **pessoa** com um login pessoal. Os usuários pertencem à organização por meio do Workspace. Os programas autônomos usam uma conta [conta de serviço ou função](/pt/iam/roles). Os usuários pertencem a uma organização, não a uma conta. Um usuário acessa recursos de conta por meio de [funções de conta atribuídas](/pt/workspace/accounts). As políticas da organização concedem permissões da organização, não acesso a recursos de conta. Por que isso é sempre um convite, e o que um `201` não promete. Políticas organizacionais e atribuições de função de conta para uma equipe de usuários. O que ele separa, o que ele deixa para trás, e quando ele entra em efeito. ## Adicionar um usuário Abra **Organization** → **Users** e, em seguida, **Invite users**. Insira um ou mais **Email addresses** e, opcionalmente, selecione **Groups**. Cada endereço recebe seu próprio convite; os resultados mostram quais convites foram bem-sucedidos. Os convites pendentes são listados na página **Users** com uma ação **Cancel invitation**. ```bash theme={null} POST /v1/users { "email": "ana@example.com", "groups": [""] } ``` ```bash theme={null} basaltic workspace user add --email ana@example.com --groups '["platform-team"]' ``` ```go theme={null} u, err := workspace.New(cfg).AddUser(ctx, &workspace.UserAddRequest{ Email: "ana@example.com", Groups: []string{groupID}, }) ``` Cada pessoa escolhe sua própria permanente [nome de usuário](/pt/compute/ssh#choose-a-username). Os convites não reservam nem substituem o nome de usuário do destinatário. `email` é o único campo obrigatório. `groups` é o mais útil: ele coloca a pessoa em seus grupos no momento em que eles se juntam, então não há nenhuma janela onde eles existem sem permissões e alguém tem que se lembrar de consertar isso. **Esta chamada sempre cria um convite**, nunca um usuário. A resposta é o convite, e a pessoa se torna um usuário quando o aceita — mesmo que já tenha um login do Basaltic. Não há nenhum caminho que adicione alguém a uma organização sem o consentimento dele. Até que eles aceitem, eles são uma linha na lista de convites pendentes, não em **Users**. É recusado com `409` em dois casos, que valem a pena dizer separadamente: | Mensagem de texto | Significado da palavra | | - | - | | O usuário já é um membro | Eles já estão nesta organização. | | Convite pendente existe | Um convite não aceito para este e-mail está pendente. Cancele-o para reenviá-lo. | Um `201` significa que o convite foi **criado**, não que o e-mail chegou. O envio é o melhor esforço: se o e-mail falhar, o convite ainda existe e a solicitação ainda é bem-sucedida, porque perder um convite que já foi gravado seria pior. Então "eles nunca receberam o e-mail" é um estado real, e a solução é cancelar o convite pendente e adicioná-los novamente em vez de esperar. ### Convites Um convite registra seu convidado real. `invited_by.type` distingue um usuário, conta de serviço ou sessão de função assumida; os convidados de máquina também incluem a identidade da conta e não têm um endereço de e-mail humano. Um convite é a metade pendente da chamada acima. Não há um endpoint separado de "criar convite" na API pública — você adiciona um usuário e um convite é o que você recebe quando ele ainda não existe. Os convites pendentes são listados em **Organization** → **Users**, abaixo dos usuários, com **Cancel invitation** em cada linha. Quando não houver nenhum, a seção diz "Nenhum convite pendente". ```bash theme={null} GET /v1/invitations DELETE /v1/invitations/{invitation_id} ``` ```bash theme={null} basaltic workspace invitation list basaltic workspace invitation cancel ``` ```go theme={null} page, err := workspace.New(cfg).ListInvitations(ctx, nil) err = workspace.New(cfg).CancelInvitation(ctx, invitationID) ``` Cancelar um convite não é o mesmo que remover um usuário: ele retira uma oferta que ninguém aceitou. [remove](#removing-a-user) em vez disso. ## Grupos Um grupo coleta os principais e detém políticas. Anexar uma política a um grupo em vez de a cada membro é a diferença entre uma alteração e *n* alterações quando as permissões da equipe são movidas. Abra **Organization** → **Groups** e escolha **Create Group**. Insira um **Name** e uma **Description** opcional. As guias **Users** e **Policies** do grupo gerenciam seus membros de usuário e anexos de política da organização. ```bash theme={null} POST /v1/groups { "name": "platform-team" } POST /v1/users/{user_id}/groups { "group": "" } POST /v1/groups/{group_id}/policies { "policy": "" } ``` ```bash theme={null} basaltic workspace group create --name platform-team basaltic workspace user add-group --group basaltic workspace group attach-policy --policy ``` ```go theme={null} c := workspace.New(cfg) g, err := c.CreateGroup(ctx, &workspace.GroupCreateRequest{Name: "platform-team"}) err = c.AddUserToGroup(ctx, userID, &workspace.UserGroupAddRequest{Group: g.ID}) err = c.AttachGroupPolicy(ctx, g.ID, &workspace.PolicyAttachRequest{Policy: policyID}) ``` Os grupos contêm apenas usuários e não são aninhados. As contas e funções de serviço usam anexos de política de conta e de política organizacional separados. As permissões da organização de um usuário incluem políticas anexadas diretamente e por meio de seus grupos. Uma atribuição de função de conta a um grupo permite que seus membros solicitem essa função; sua política de confiabilidade ainda deve aceitar cada usuário assumindo. ### Onde anexar uma política Anexe políticas da organização a grupos quando a concessão descrever uma equipe ou trabalho. Use anexos diretos do usuário para exceções individuais. As permissões de conta pertencem a funções e contas de serviço, não a usuários ou grupos. As políticas em linha são uma terceira opção e uma mais restrita — veja [managed and inline policies](/pt/iam/policies#managed-and-inline-policies). ## Removendo um usuário Abra o usuário, escolha **Settings** e, em seguida, **Remove user** na zona de perigo. Digite o valor de confirmação exibido antes de confirmar. ```bash theme={null} DELETE /v1/users/{user_id} ``` ```bash theme={null} basaltic workspace user remove ``` ```go theme={null} err := workspace.New(cfg).RemoveUser(ctx, userID) ``` A remoção de um usuário o remove de **esta organização**. Ele não exclui o login do Basaltic, que pode pertencer a outras organizações, e não exclui nada que eles criaram — os recursos pertencem à conta, não à pessoa que os criou. A remoção é atômica e leva toda a sua pegada nessa organização com ela: associações de grupo, anexos de política, políticas inline, seu limite de permissão e, finalmente, a própria associação. Isso significa que re-adicionar o mesmo e-mail mais tarde produz um usuário com **sem permissões** — nada disso volta. Se você estiver removendo alguém temporariamente, anote em quais grupos eles estavam primeiro: nada mais faz isso. A remoção encerra a associação a esta organização. Revise as sessões de função do usuário como parte do desligamento; as páginas de sessão de STS da conta mostram o principal de origem e permitem revogação explícita. ## Permissões Essas APIs usam `https://workspace.basaltic.sh`. Suas ações estão no namespace `workspace:` e devem ser concedidas através de políticas da organização. | Fazendo isso | Necessidades | | - | - | | Adicionar um usuário | `workspace:AddUser` | | Remover um usuário | `workspace:RemoveUser` | | Criar um grupo | `workspace:CreateGroup` | | Adicionar ou remover um membro | `workspace:ManageGroupMembership` | | Anexar ou separar uma política de organização | `workspace:AttachPolicy` / `workspace:DetachPolicy` | Consulte [Permissões de espaço de trabalho](/pt/workspace/permissions) para obter informações sobre as verificações de recursos e as ações de atribuição de função de conta.