Pular para o conteúdo principal

Visão Geral

A CrewAI migrou as organizações do sistema de funções original (“RBAC legado”) para o RBAC v2. Esta página explica como sua conta fica depois da migração, como os termos antigos correspondem aos novos e o que verificar quando sua organização estiver no RBAC v2. O objetivo da migração foi manter o acesso de todos o mais próximo possível do que era. Suas funções legadas e configurações de compartilhamento foram transformadas em equipes e concessões. Ninguém precisou configurar nada novamente.

Termos antigos, termos novos

Como sua conta fica depois da migração

A equipe Administrators

Todos que eram owners da organização, ou tinham a função legada Owner, estão na equipe gerenciada pela CrewAI Administrators. Essa equipe tem acesso total a tudo na organização. Owners não recebem mais acesso apenas por serem owners. Se você remover alguém da equipe Administrators, essa pessoa perde o acesso total.

Uma equipe para cada função legada

Cada função legada (exceto Owner) se tornou uma equipe personalizada:
  • A equipe tem o mesmo nome da função, por exemplo Member, Developer ou Support.
  • A equipe tem as mesmas pessoas da função. Pessoas sem função foram tratadas como Member, então estão na equipe Member.
  • As permissões de funcionalidade da função se tornaram funções da equipe. Consulte Permissões de funcionalidade.
  • Tudo o que estava compartilhado com a função foi compartilhado com a equipe.
Essas são equipes personalizadas comuns. Você pode renomeá-las, alterar seus membros e funções ou desativá-las.

Compartilhamento

Todo compartilhamento foi transferido:
  • Um recurso compartilhado com uma pessoa agora é uma função dessa pessoa naquele recurso.
  • Um recurso compartilhado com uma função legada agora é uma função da equipe correspondente naquele recurso.
A função foi escolhida a partir do nível do compartilhamento. Consulte Níveis de compartilhamento.

Recursos que as pessoas possuem

Quem era dono de um recurso manteve o controle total sobre ele: A partir de agora, quem cria um recurso se torna automaticamente seu Admin.

Service accounts

Service accounts não tinham função legada, então não entraram em nenhuma equipe. Elas receberam:
  • Automation Admin em cada automação que possuem.
  • Application Connection Admin em cada conexão de aplicação que possuem.
  • Studio Project Admin no escopo de Organização, para que ainda possam excluir projetos do Studio pela API.

Permissões de funcionalidade

Esta tabela mostra as funções que cada permissão de funcionalidade legada deu à equipe da função. Todas estão no escopo de Organização, salvo indicação em contrário.
Se sua organização não ativou a configuração Git repositories RBAC, as equipes cuja função legada podia criar automações (crews_dashboards Manage ou studio_projects Manage) também receberam Git Repository Operator, para que ainda possam escolher um repositório ao fazer deploy.

O que a equipe Member padrão tem

A função legada padrão Member se tornou a equipe Member. A menos que você tenha alterado a função Member antes da migração, a equipe Member tem:
  • Studio Project Viewer, Studio Project Creator e Automation Creator
  • Agent Viewer
  • Skill Operator e Application Connection Creator
  • Agent Control Plane Viewer e ACP Policy Viewer
  • Git Repository Operator, se a configuração Git repositories RBAC estava desativada
  • Uma função em cada recurso que estava compartilhado com a função Member, como variáveis de ambiente da organização

Níveis de compartilhamento

Cada compartilhamento se tornou uma função naquele recurso. Quando um compartilhamento tinha mais de um nível, foi usado o nível mais alto.

Automações

Projetos do Crew Studio

Outros recursos

Os compartilhamentos legados destes recursos não tinham nível. A nova função depende do nível legado da pessoa ou da função com quem o recurso foi compartilhado.

O que funciona de forma diferente agora

A maioria das pessoas mantém o mesmo acesso. Estas são as diferenças que você tem mais chance de notar.

Pessoas ganham acesso

  • Todos na equipe Member podem abrir todos os projetos do Studio da organização, porque a função Member tinha Manage no Studio. Antes, os membros viam apenas os próprios projetos e os projetos compartilhados com eles. Abrir um projeto é somente leitura: executá-lo ou editá-lo ainda exige uma função mais alta naquele projeto.
  • Os compartilhamentos de automações ficaram mais simples. Não existe uma função de automação somente de visualização, então qualquer pessoa com um compartilhamento em uma automação agora pode executá-la, ver seus traces e responder a solicitações human-in-the-loop.
  • As configurações não são mais exclusivas dos owners. Billing, Integrations, Theme e o gerenciamento de membros antes exigiam um owner. Agora qualquer pessoa com Usage and Billing Admin, Organization Admin ou Identity and Access Admin pode abri-los.
  • Conexões LLM e variáveis de ambiente compartilhadas ficam visíveis. Pessoas com um compartilhamento podem ver a conexão ou a variável na respectiva página de configurações. Environment Variable Viewer pode revelar o valor da variável.

Pessoas perdem acesso

  • O acesso somente leitura a algumas configurações terminou. Read em usage_dashboards, secret_providers, default_settings e workload_identity não deu nenhuma função. Para restaurá-lo, dê à pessoa ou à equipe a função correspondente da tabela Permissões de funcionalidade.
  • Usar as telas de chat e kickoff de uma automação exige uma função nela. Antes, qualquer membro podia iniciar uma execução, verificar seu status ou usar a memória pela Crew UI de uma automação sem um compartilhamento. Agora isso exige pelo menos Automation Operator naquela automação.
  • Operators não podem ver valores de variáveis de ambiente de automações nem excluir execuções. Ver valores de variáveis de ambiente agora exige Automation Editor ou Automation Admin. Excluir execuções exige Automation Admin.
  • Editors não podem compartilhar nem excluir uma automação. Quem tinha manage_settings sem full_access agora é Automation Editor. Compartilhar e excluir exigem Automation Admin.
  • Conexões de aplicação compartilhadas ficam visíveis apenas para o dono e para a equipe Administrators, até que alguém as compartilhe pelo botão Share da conexão.
  • Service accounts e a API de pessoas. Chamadas de API que convidam usuários, removem usuários ou alteram suas funções exigem a função Identity and Access Admin. Dê essa função a qualquer service account que use esses endpoints.

O gerenciamento de acesso funciona de forma diferente

  • A página Roles foi desativada. As funções legadas não controlam mais o acesso, então alterá-las não teria efeito. Use Settings → Teams e Settings → Members.
  • Convites não definem uma função. Novas pessoas entram sem acesso. Adicione-as a uma equipe depois que aceitarem o convite, ou mapeie um grupo de SSO para uma equipe para que isso aconteça automaticamente.

Depois da migração: um checklist

1

Verificar a equipe Administrators

Vá em Settings → Teams e abra Administrators. Confirme que estão nela apenas as pessoas que devem ter acesso total.
2

Revisar as equipes criadas a partir das suas funções

Cada função legada agora é uma equipe com o mesmo nome. Verifique seus membros e funções. Renomeie equipes se um nome mais claro ajudar e desative as equipes de que você não precisa mais.
3

Decidir quem deve ver todos os projetos do Studio

A equipe Member pode abrir todos os projetos do Studio. Se isso for amplo demais, remova Studio Project Viewer da equipe Member e compartilhe os projetos com as pessoas que precisam deles.
4

Planejar como novas pessoas recebem acesso

Novos membros começam sem acesso. Decida em qual equipe as novas pessoas entram e adicione-as depois que aceitarem o convite. Com SSO, configure mapeamentos de grupos.
5

Verificar suas service accounts

Em Settings → Service Accounts, dê Identity and Access Admin a qualquer service account que convide ou gerencie usuários pela API.
6

Restaurar o acesso somente leitura às configurações, se necessário

Se alguém dependia de acesso de leitura a uso, provedores de segredos, padrões do Crew Studio ou workload identity, dê a essa pessoa a função de organização correspondente.

Precisa de Ajuda?

Fale com o nosso time de suporte se algo parecer diferente do esperado depois da migração.